home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Cream of the Crop 3
/
Cream of the Crop 3.iso
/
utility
/
dea201.zip
/
DEA.DOC
< prev
next >
Wrap
Text File
|
1993-12-01
|
183KB
|
3,671 lines
█████████████ █████████████████ ███████
███ ███ ██ ██ ██
███ ███ ██ ██ ██
███ ███ ██ ██ ██
███ ███ ██ ██ ██
███ ██ ██ ██ ██
███ ██ ██ ██ ██
███ ██ ███████████ █████████████████████
███ ██ ██ ██ ██
███ ███ ██ ██ ██
███ ███ ██ ██ ██
███ ███ ██ ██ ██
███ ███ ██ ██ ██
█████████████ █████████████████ ██ ██
The Data Encryption Algorithm
Release v.2.00
___________________________________________
An Advanced Cryptographic Software Tool
For Confidential & Private
Computer Information
In the 1990's
And Beyond
Documentation and User's Reference Manual
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Copyright (c) 1993 by Nellis du Maurier Information Security
All Rights Reserved
Published and printed in Canada, November 1st, 1993
Version Release Dates
____________________________________________________
Initial DEA v.2.00 (ß) release: August 30, 1993
Final Release Date: November 1st, 1993
Release v.2.01: December 1st, 1993 (current version)
Distribution: Worldwide
----------------------------------------------------
**************************************
* _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- *
* *
* Washington, having been asked by *
* an officer on the morning of a *
* battle, what were his plans for *
* the day, replied in a whisper, *
* Can you keep a secret? On being *
* answered in the affirmative, the *
* general added --so can I. *
* *
* _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- *
**************************************
LICENSE AGREEMENT
Nellis du Maurier Information Security hereby grants
non-registered users a limited license of thirty (30)
days. Trial evaluation period shall become effective from
the date of acquisition of The Software. During this time
licensee may determine the suitability and applicability of
this software to their needs. Licensee may use, copy, and
distribute The Software subject to the following conditions
and restrictions:
(i) The Software and its documentation may not be
modified in any manner whatsoever, except that it may
be archived into a single file for ease of distribution
or uploading to bulletin board systems. (ii) The Software
may not be disassembled, reassembled, reverse engineered,
or de-compiled. (iii) No fee or price may be
charged for The Software or accompanying documentation
beyond a reasonable amount to cover the cost of
distribution of The Software. (iv) The Software and its
documentation may not be translated into any other
language without the prior written approval of the
publisher. (v) The documentation file DEA.DOC must
accompany the executable file DEA.EXE. (vi) The Software
is not distributed in conjunction with any other product.
(vii) Licensee is not authorized to rent, lease, or
sublicense The Software. (viii) Licensee is not entitled
to any source code. (ix) Licensee may not create
derivative works of The Software or incorporate any part
thereof into another computer program or product.
DISTRIBUTION
The DEA Software package is a Shareware product because it
is distributed through public information channels so that
prospective buyers can have the opportunity to evaluate the
product before making the final purchase decision. if you
decide to continue using The Software beyond the thirty (30)
day trial evaluation period, then you are under both legal
and moral obligations to register this software product with
Nellis du Maurier Information Security; the Data Encryption
Algorithm (DEA Release v.2.00) Software IS NOT FREE.
THE SHAREWARE DEFINITION
It is important to understand that 'Shareware' is not a
type of software. It is a method of distributing software
to prospective buyers. In essence, a shareware product
extends a measure of good faith to the potential purchaser
in that he / she is given the opportunity to evaluate the
software before buying it. This is analogous to taking a
car for a test drive before you buy it. Since the operating
overhead is low, the shareware prices are low also. Shareware
offers the best money-back guarantee: if you don't use the
product, you don't pay for it. There are good and bad
programs in both the Shareware and commercial domain;
Shareware is not to be thought of as second-hand software.
While some may think that Shareware is second grade software,
for, if it was really good quality, it would be called
'commercial'. The best reply to this type of attitude is to
remember that Shareware is also a commercial enterprise. There
is, not surprisingly, far more software variety and
affordability to be found in Shareware. There are many truly
useful software products only marketed via Shareware channels.
By supporting the shareware software provisions, you assure
yourself the continued existence and support of software
you have chosen to use on a routine and daily basis. This
honesty also carries forward to future programmers from who's
products you may also benefit. The DEA is user-supported
software.
COPYRIGHTS
The Data Encryption Algorithm (DEA) version 2.00
programs and documentation are copyright 1993AD and are
the licensed property of the publisher:
Nellis du Maurier Information Security
All commercial rights and rights of translation into
foreign languages are reserved by the publisher.
Unauthorized duplication is strictly prohibited.
PATENTS
The Data Encryption Algorithm, DEA Release v.2.00
incorporates cryptographic technology never before used
in cryptographic designs. These new designs cover the
DEA key data structure, the production of one-time-pads,
and the DEA v.2.00 Cipher Function. Patents are pending
for these unique designs.
DISCLAIMER OF LIABILITY
Licensee must accept and acknowledge the fact that the
Data Encryption Algorithm (DEA v.2.00) is in the process
of peer evaluation. Unlike other computer software,
competent computer information security algorithms must
undergo a period of rigorous testing, inspection, and
analysis by trained experts. The availability of The
Software is designed to encourage competent peer
evaluation of this lengthy process, and will ultimately
benefit you, the end user, in making an intelligent choice.
Nellis du Maurier Information Security has no control over
the conditions under which licensee operates and uses
The Software and therefore cannot warrant the performance
and results so obtained from the use of these products.
Nellis du Maurier Information Security shall not
be responsible for problems caused by hardware failure, or
operating system difficulties when using The Software.
Nellis du Maurier Information Security shall not
in any case be liable for incidental, consequential,
indirect, or other damages resulting from use of The
Software.
Nellis du Maurier Information Security shall not in any case
be held legally responsible for any costs incurred by the
use of The Software resulting in lost profits, lost
revenues, lost data, costs of re-creating lost data, costs
of substitute software, or to persons other than licensee
for other costs, including, but not limited to legal and
law enforcement.
Nellis du Maurier Information Security shall not in any case
be held legally responsible for obstruction of justice.
In situations where the Data Encryption Algorithm obstructs
federal law enforcement efforts, the licensee is under
full legal obligation to disclose the DEA key data to allow
the recovery of the indicated plain text document(s). By
using The Data Encryption Algorithm Software, licensee agrees
to hold harmless Nellis du Maurier Information Security
from all legal costs involved and / or incurred in
the process of litigation and / or prosecution.
WARRANTY
Nellis du Maurier Information Security warrants The
Software to operate in accordance with the accompanying
documentation and to be free of defects. This warranty
shall also cover the shipping media when The Software is
ordered directly from Nellis du Maurier Information
Security. Data integrity of The Software cannot be
guaranteed when The Software has been obtained from any
other source. Further, great care has been exercised with
respect to both The Software and the Security Analysis.
The DEA v.2.00 was designed, written,
and published November 1st, 1993 by:
Nellis du Maurier Information Security
33 Isabella St., Ste. 1005
Toronto, Ontario M4Y 2P7
Canada
Version Release History
v.2.00 November 1st, 1993
v.2.01 December 1st, 1993
Current version: 2.01
█████████████ █████████████████ ███████
███ ███ ██ ██ ██
███ ███ ██ ██ ██
███ ███ ██ ██ ██
███ ███ ██ ██ ██
███ ██ ██ ██ ██
███ ██ ██ ██ ██
███ ██ ███████████ █████████████████████
███ ██ ██ ██ ██
███ ███ ██ ██ ██
███ ███ ██ ██ ██
███ ███ ██ ██ ██
███ ███ ██ ██ ██
█████████████ █████████████████ ██ ██
Release v.2.00
TABLE OF CONTENTS
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Chapter One
═══════════════════
1.1 PURPOSE OF THE DATA ENCRYPTION ALGORITHM
1.2 SUMMARY OF FEATURES OF THE DATA ENCRYPTION ALGORITHM
1.3 SYSTEM REQUIREMENTS
1.4 THE DATA ENCRYPTION ALGORITHM - QUICK TECHNICAL OVERVIEW
1.5 WHY USE THE DEA AS AN ENCRYPTION TOOL TO PRESERVE PRIVACY?
1.6 THE PURPOSE AND USE OF CRYPTOGRAPHY
1.7 VARIETIES OF CONFIDENTIAL INFORMATION
Chapter Two
═══════════════════
2.1 GETTING STARTED WITH THE DATA ENCRYPTION ALGORITHM
2.2 INSTALL.BAT AND SETTING THE DOS PATH
* 2.3 RUNNING THE DEA FOR THE FIRST TIME
2.4 LEARNING TO USE THE DEA VIA AUTOMATED BATCH FILES
* 2.5 THE DEA COMMAND LINE SWITCHES
Chapter Three
═══════════════════
* 3.1 DEA DEFAULT FILE NAMING CONVENTIONS
3.2 DOS FILE TYPES & FILE ATTRIBUTES
3.3 THE DEA.KEY FILE LOCATION ERROR
3.4 ADVANCED METHOD OF LOCATING THE DEA.KEY FILE
VIA THE DOS REDIRECTION PIPE
3.5 MAKING THE DEA.KEY FILE READONLY
3.6 THE DEA EMBEDDED FILE PATH
3.7 DEA AUTOMATIC PROCESSING FILE CLEAN-UP
3.8 THE DEA LOG FILE
3.9 THE DEA KEY FILE
3.10 VALID DEA KEYS
Chapter Four
══════════════════
4.1 THE DEA ONE-TIME-PAD SIZE SETTING AND INFORMATION CONTENT
4.2 THE DEA UTILITIES - GENKEY, KEYVIEW, MFD
4.3 SECURE TRANSMISSION OF KEYS
4.4 THE DEA AND PRIVATE E-MAIL
4.5 DEA CIPHERTEXT CORRUPTION
Chapter Five
══════════════════
5.1 THE OPERATING SYSTEM
5.2 DATA SAFEGUARDS AND THE INTEGRITY OF DATA
5.3 PRE-DEA FILE COMPRESSION
5.4 COMPRESSION OF DEA CIPHERTEXT
5.6 DEA v.2.00 ENCRYPTION TIMING TESTS
5.7 MULTIPLE ENCRYPTION AND PRACTICALITY
Chapter Six
══════════════════
6.1 PREVIOUS VERSIONS OF THE DATA ENCRYPTION ALGORITHM
6.2 COVERT AND PRACTICAL CRYPTANALYTIC TECHNIQUES
6.3 DATA ENCRYPTION AND THE LAW
6.4 THE DEA ADVANCED COMMERCIAL VERSION - DEA ACV v.2.00
6.5 DEA PROBLEM REPORTS
Chapter Seven
══════════════════
7.1 PRELUDE TO THE DEA SECURITY ANALYSIS
7.2 THE DEA v.2.00 SECURITY ANALYSIS
Chapter Eight
══════════════════
8.1 REGISTRATION AND ORDER FORM
8.2 DEA USER FEEDBACK
8.3 THE DEA v.2.00 OPERATING SPECIFICATIONS
Chapter Nine
══════════════════
9.1 THE DEA v.2.00 FILE SIZE DOUBLING PROBLEM
Additional Information
══════════════════════
APPENDIX
════════
TIMING FUNCTION
ERROR MESSAGES
WHY WAS THE GENKEY PROCEDURE NOT AUTOMATED?
DEA COMMERCIAL VERSION
CLEARING THE INTERNAL KEY DATA STRUCTURE
A HELPFUL HINT FOR FREQUENT COMMAND LINE USAGE
ANOTHER METHOD OF CREATING THE DEA KEY
PROGRAM EXIT CODES - DEA.EXE only -
ACKNOWLEDGMENTS
═══════════════
Chapter One
═════════════════
1.1 PURPOSE OF THE DATA ENCRYPTION ALGORITHM
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
The Data Encryption Algorithm, hereinafter referred to as the DEA, is an
algorithm designed to protect and maintain the privacy and confidentiality
of today's electronic computer data. It is a software tool to be used
whenever and wherever privacy must be maintained in personal computer
MS-DOS(tm) information files. The information security strength of the
DEA far exceeds any of today's cryptographic software tools, including
the popular RSA hybrid public key encryption systems. The DEA is a very
serious cryptographic tool for serious information security applications.
The DEA v.2.00 incorporates the most advanced cryptographic designs ever to
be released into the private sector. As you read this document, you will
gain an understanding and appreciation of cryptography, its principles, its
applications, and its limitations.
While no encryption algorithm can provide an absolute and eternal blockade
to the original plain text, the DEA has been designed to offer both
extremely high security along with ease of use in a compact easy to use
package. Data encryption in the modern information age is the cheapest
and most convenient method of handling sensitive computer data. It provides
unrestricted access to authorized personnel, while providing true security
to all others who's business is snooping about for secrets.
1.2 SUMMARY OF FEATURES OF THE DATA ENCRYPTION ALGORITHM
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Below are listed the main features of the DEA v.2.00:
o an extreme level of security far beyond the 16 year old DES standard,
including the new 128 bit key IDEA(tm) cipher and double-length DES keys
o 1,440 bit (180 byte) key
o the actual key is not used directly as with other common algorithms
o sophisticated Cipher Function unlike any previous cipher design
o all relationships between plaintext and ciphertext completely eliminated
o has the capability of creating ciphertext carrying zero information bits
o is extensible to meet future needs via extendable keys & keyspace
o user definable operating speed to match your computing hardware
o extremely large keyspace which can be extended even further
o very easy to operate
o may be operated in either command line mode, or interactive mode
o can be used with batch file processes
o a near one-time-pad implementation without the fuss & mess of the OTP
o a completely new and unique key structure which cannot be memorized
o integrated automatic military wipe to permanently erase all plaintext
o automatic processing file clean up
o error checking and detailed error messages
o full error trapping and error exit codes
o automatically updated program log file
o key ID eliminates the need to physically type the key by the operator
to help in minimizing TEMPEST electronic signal emissions
o ASCII DEA key text may be embedded into files before they are encrypted
o DEA default and user-priority file naming conventions
o can be used on all MS-DOS(tm) files, including hidden & system
o user selectable one-time-pad size
o separate utility to generate new DEA keys
o separate utility to extract and view existing keys in ASCII format
o commercial version's effective keyspace is 2^2,304,000 or 256^36,000
** in depth general analysis and discussion of cryptology
** security proof
disadvantages
x can become very slow with large OTP settings
x REQUIRES FAST HARDWARE, NO PC /XT support
x will double the size of the input file, forcing
the use of a file compression utility prior to the DEA
x keys are long and cannot be humanly memorized
x the DEA is not self-synchronizing; if DEA ciphertext
is deliberately tampered with, then recovery of
further plaintext will not be possible
x conventional key distribution problems apply, as the
DEA is not a public key cryptosystem
1.3 SYSTEM REQUIREMENTS
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
o For IBM PC AT, and other systems (80386, 80486, and Pentium(tm) )
FAST (33Mhz +) 386 or 486 processor HIGHLY RECOMMENDED
o 128K memory
o one or two floppy drives, 1.2MB, or 1.44MB and / or a hard disk, OR
ANY external storage device accessible by a DOS file pathname
o MS-DOS 4.01 or higher
o any type monitor
x will NOT function with PC XT systems
1.4 THE DATA ENCRYPTION ALGORITHM - QUICK TECHNICAL OVERVIEW
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
The DEA is unique in that it is neither a transposition, nor a strict
substitution based algorithm, although it is more correctly considered to
be a substitution type algorithm. The DEA is a one-time-pad cipher system
which comes as close as possible to a true one-time-pad system. A true OTP
is one in which the key is as long as the message itself. However, for
practical reasons, the one-time-pad ideal is simply not ideal in real
world applications. The one-time attribute of the DEA stems from the fact
that the DEA never uses the same piece of key information twice. Further,
the DEA does not cryptographically combine the plaintext with the key in
any manner. The DEA's ciphertext will resist all attempts to correlate
known plaintext with corresponding ciphertext. Any such attempts will fail
because the DEA ciphertext output is as variable as the plaintext submitted
to the algorithm, thus even dictionary type attacks will result in failure.
There exists no method whatsoever to derive either plaintext or key
information from an examination of the DEA ciphertext. The DEA keyspace in
version 2.00 is set at a maximum of 256^180, or 2^1,440 which is 25.714
orders of magnitude larger than the DES algorithm. The design of the DEA
allows for an even larger keyspace of practically unlimited length. As a
side note, the DEA's total number of keys is represented by a number of more
than 412 digits. Compare the keyspace of the DES at 72,057,594,037,927,940.
Registered users can expect a keyspace no less than 2^2,304,000 or
256^36,000 which is 41,142.857 orders of magnitude larger than the DES. It
is important to state here that while the DEA is extremely secure, it is
not unbreakable. The only avenue available to breaking the DEA is by the
brute-force strategy of trying all possible keys. Despite this sobering
fact, users should not be deterred in using the DEA. Any claim that a
particular cryptographic system "is unbreakable" is a deception of fact;
such a claim is a naive assertion on the part of the designer to pat
himself on the shoulder for his nearsighted accomplishment. Cryptography
cannot supply an eternal, forever information blockade. It can, however,
provide a 'time lock' barrier. Indeed, cryptography is the next best
alternative to completely deleting the information.
The DEA is a slow algorithm because it must generate a one-time-pad for
each and every 8-bit byte it will process. If our input file, for example,
is 1000 bytes long, and the user has selected a one-time-pad size of 10,000
digits, then when the DEA is finished, it will have computed a total OTP
of length (10,000 x 1,000) + (10 x 10,000) = 10,100,000 digits.
The one-time-pad size of the DEA can be adjusted by the user from 1300 to
20,000. Be aware, however, that the larger the OTP, the slower the DEA
will operate. There is, however, no real difference in security provided
by the DEA with different one-time-pad lengths. That is, an OTP of 1,500
digits will be just as secure as an OTP of 15,000 digits; the only
differences are in processing time, and meaningful information bits within
the ciphertext. Larger OTP settings will drastically decrease original
information bits, while smaller OTP settings will increase speed and
increase the information bits from plaintext to ciphertext, although those
bits will be scrambled. Thus, you can adjust the DEA speed to match the
type of computing hardware you have, and the size of the data file to be
enciphered.
Perhaps the most unusual aspect of the DEA key is that it is not used
directly. All other systems which employ a key, use it directly. That is,
they combine the key with the plaintext via some algorithm. Even the well
respected RSA directly combines the key with the plaintext leading to a
certain type of ciphertext attack. Whenever the key is combined directly
with the plaintext in this manner, very subtle relationships between key and
plaintext can be shown to exist. This is what the cryptanalyst is trained to
seek out and exploit; it is his bread-and-butter. The DEA must first go
through two (2) stages of key translation per file block. Reversing the two
translations is not possible. It is only after these two key translations
that a useable one-time-pad is created and used by the Cipher Function to
encrypt the data.
1.5 WHY USE THE DEA AS AN ENCRYPTION TOOL TO PRESERVE PRIVACY?
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
The DEA is the only currently available encryption algorithm for the
MS-DOS(tm) personal computer environment which comes as close as possible
to the ultimate one-time-pad cipher ideal without the impractical
and cumbersome consequences implied by the one-time-pad system. The DEA
far exceeds the industry standard DES algorithm in cryptographic strength,
while the mathematics of the DEA imply that it is, at least, on an equal
footing with the RSA algorithm, if not more secure than this popular public
key cryptosystem. Although the RSA is intuitively thought of as an extremely
secure cryptosystem, it is not so because no one uses it in its 'native' mode.
That is, the RSA system is commonly used as a hybrid system wherein a RSA
key is used to encipher a fast conventional cryptosystem session key. It is
actually, another completely different encryption algorithm which encrypts
your data, not the RSA. The RSA only encrypts the key you used to encrypt
the actual file data with the other algorithm. In the popular freeware PGP
v. 2.00 by Philip Zimmermann, the file data is enciphered by the IDEA(tm)
conventional 128-bit key cipher, and not the RSA. The RSA of PGP v.2.00
only encrypts the 128-bit session key, not your sensitive data. The
attentive reader may wonder, then, what the advantages of such a hybrid
system may be. In such a design, there are only 256^16 total keys available.
This is only 8.89% of the total DEA v.2.00 keyspace. Hybrid RSA systems do
offer a viable solution to the problem of key distribution, especially
people you have never met. This is a problem with the DEA design. However,
even digital signatures of the RSA can pose authentication problems.
Thus, hybrid RSA systems are only as secure as the fast enciphering
algorithm, in the case of PGP v.2.00, the security derives from the IDEA(tm)
cipher. All other services and capabilities of such hybrid systems derive
from the RSA algorithm shell.
The DEA software package provides you with all the most advanced software
tools available to manage your information effectively, cleanly, compactly,
and without worry.
The DEA is an extremely secure and strong algorithm because its ciphertext
will resist any and all attempts to derive algorithm dependencies which
could result in successful cryptanalysis. Further, the DEA's keyspace is
extremely large, far larger than all other algorithms in common usage today.
Since there are no analytic shortcuts available in the DEA v.2.00, the
potential attacker is obliged to undertake the method of last resort: brute-
force.
The algorithm's Cipher Function is the main fortress of security as it
shapes and defines the many cryptographically interesting and unique
features of the DEA. The DEA incorporates many truly unique designs
never before used in cryptography. The DEA represents a complete
departure from traditional cryptographic designs. It is surmised that
the DEA design will bring about a new modus operandi with regard to how
future cryptographic systems are designed.
While Personal Computer users have had their pick of the many information
security tools available, there has been very little creativity in the way
of fresh cryptographic ideas which can stand on their own, and stand up to
close scrutiny. The DEA v.2.00 which you are now reviewing, embodies very
advanced technology in an easy to use and user-friendly environment.
The DEA represents an investment of approximately twenty three (23)
months of research, design, and programming. It is definitely not
'snake oil'. The DEA evolved into its present form; it is a transcribed
work from v.1.00. Most of the available PC software encryption tools
evaluated, do not state explicitly the precise nature and operating
characteristics of the algorithms, let alone a proof of the security
provided by merchants of such products. The typical approach of many
such companies is to either implement the standard DES algorithm in a
new user friendly reincarnation, or to develop their own proprietary
algorithms which are usually faster and less secure than even the DES.
If you have reviewed numerous Shareware encryption packages, you will
notice that they are basically cut from the same ideological cloth.
You, as the end user, can make a preliminary judge- ment by examining
the length of the key. The longer, the better, up to a point. Next,
you should examine the way in which the ciphertext itself is created.
If the plaintext bits are combined directly, in any manner, with
something the algorithm produces as ciphertext, then the cryptanalyst
has a job.
It is very important for both end users and crypto software developers to
avoid a false sense of security. Over zealousness on the part of a
software developer can be inspired in users of such systems which claim to
be "unbreakable". Nothing could be further from the truth! Any crypto
system or algorithm can be broken in theory, including a one-time-pad. The
one-time-pad makes things extremely difficult, but still not impossible.
If the algorithm defends the information for the time span in which the
attacker could gain a monetary, informational, or other advantage, then
it has done its job respectfully.
The best cryptosystems are those whose ciphertext cannot be used against
the algorithm itself by a cryptanalyst. If all relations between plaintext
and ciphertext are successfully broken by an algorithm, then there is no
other option available save a brute-force attack. This property along
with a vast keyspace are the two main features which are the hallmarks of a
respectable cryptographic system. The DES was such a system sixteen (16)
years ago, but both intense research and computing speed advances have
resulted in an algorithm which 16 years later should not be used to protect
anything more sensitive than a love affair. In fact, 16 years after the
DES was commissioned into service, it can today be broken routinely in less
than 24 hours via brute-forcing the algorithm. In the 1990's the DES is
also succumbing to new analytic techniques. Today the DES is entrenched
in business, government, personal, and corporate affairs; it does the job.
It is vital to understand that cryptography is only a component of an
overall procedure designed to maintain information security in the
information age we all live in today. Clearly, the data encryption standard
of yesteryear cannot be relied upon today for high security applications.
When choosing an information security tool, the evaluation should comprise
some of the following questions:
1. how much security do I need ?
2. what level of security does the information deserve ?
3. what are the possible consequences of security breach ?
4. who most likely poses a latent threat, and what resources do
they have on hand ?
5. how much time am I willing to invest in the protection
of the information ?
6. is the information security tool itself reliable and does it
provide adequate and time-proven security ?
7. how long must the information be maintained private
and confidential ?
8. what would the consequences be if I cannot recover the information
myself ?
1.6 THE PURPOSE AND USE OF CRYPTOGRAPHY
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Today, with the availability and widespread usage of personal computers
in the home, business, and government environments, along with the popular
growth of information services such as electronic bulletin board systems
(BBS's), there is a growing need to understand what types of data should
be considered sensitive, and what measures should be taken to ensure
sensitive data is maintained in a confidential state.
Cryptography is the science dealing with the transformation of plain and
intelligible information into the exact opposite, that is, information
which seems to be gibberish. However, the information is not gibberish, it
has simply been made to look like a meaningless jumble of now useless
information. The goal of cryptography is to render the meaning contained
in natural language into a new 'language' which cannot convey meaning in
natural language. For example, you might want to take a meaningful English
sentence and have it translated into several other languages. Now, the
meaning of the sentence exists in several languages, but because we are
unfamiliar with these languages, the message is no longer intelligible;
these other languages convey meaning, but not to us; and so it is with our
intent here: cryptography is the art of translation into meaninglessness.
Cryptography deals with the many ways in which the entropy of the
information can be modified such that order, structure, and patterns of
natural language can be translated into disorder and randomness.
Thus, encryption is the overall process of encoding plain
information (the plaintext) into a new form which disguises and hides the
intelligence of the message (the ciphertext). The intelligence of the
message is preserved, but now the intelligibility of the message is lost.
However encryption is a reversible 'reaction', that is, the intelligence
of the message can be recovered and therein lies the utility of cryptography
and the process of enciphering data: it preserves the intelligence of the
information while cloaking it in an envelope of meaninglessness for those
specifically not meant to see it, just like placing a lock on a box, or a
letter into an envelope.
In modern times, cryptography is intimately involved with the vast
production of information by governments, military affairs of nations, and
to a lesser degree, in banking, industry, and commerce. The application of
the principles of cryptography today extend far beyond the necessary and
logical use by Julius Caesar. Today, cryptography has extended to encompass
military satellite transmissions, television, speech, facsimile machines,
and the cellular telephone. In short, the dramatic rise of cryptography
is directly attributed to the enormous volumes of information we all
use and generate on a daily basis. We are, after all, in the information
age. And in this information age, we must develop the habit of recognizing
what type of information is confidential, and to preserve the
confidentiality of sensitive information, we are obliged to use tools
which operate upon this information, specifically, we desire to maintain
the intelligence of the information while destroying its intelligibility.
Although great strides have been made in man's quest for information
privacy via a great variety of cryptographic techniques, the basic idea
behind this science has remained unchanged from Caesar's day. His need
then was the very same as our need today. The only difference is that we
use a great number of electronic information interchange devices.
1.7 VARIETIES OF CONFIDENTIAL INFORMATION
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
The following listing should help users recognize and decide what types
of information merit privacy and deserve confidentiality.
1. any information you wish to MAINTAIN, but NOT SHARE with a
particular set of other people for whatever reasons
( *** THE MOST ABSOLUTE AND FUNDAMENTAL REASON FOR THE EXISTENCE OF
THE SCIENCE OF CRYPTOGRAPHY. *** )
2. company employee data files containing:
- medical records
- salary records
- absenteeism records
- other personnel records such as drug dependencies,
alcohol counselling, family matters, legal matters, etc.
3. any situation in which space is shared with others
whose honesty, trustworthiness, and integrity has
not fully been ascertained
4. company information, such as:
- company information transmission from branch-to-branch
- negotiating position
- internal operating procedures, or private policy statements
- proprietary data, industrial trade secrets
- sensitive sales information
- company employees operating in foreign nations
- legal matters
- financial matters
- illegal business activities
- results of research work
- business plans and budgets
- manufacturing process
- secret formulas (for example, Coka Cola, Kentucky Fried Chicken)
- new product developments
- future plans / expansion
- identity of customers and their purchases
- violations of government regulations
- information on competitors
- membership lists
5. two or more people
- two lovers
- an organization of peoples with a common goal, perhaps not
compatible with others
- situations where the content and context may be offensive to others
6. General areas of human endeavour where encryption is used:
- government (budgets, internal memos, secret projects, reports, etc.)
- military communications
- banking (money transfers)
- private sector industry and commerce
- communications
- consumer electronics (your personal organizer, etc.)
- education (grading results)
7. Confidential medical records
- patient medical records
- medical test results
8. Law Enforcement - Secret Service
9. Geological
- survey data (such as oil, mineral, gas)
- historical data, for example, previous land usage
10. professionals with sensitive client information, such as:
- doctors
- psychiatrists
- lawyers
- accountants
- auditors
11. Social and behavioral professionals who have collected
sensitive data and are concerned about the subjects'
right to privacy. (example: subjects of Masters and Johnson studies)
- psychological evaluations: your visit to the 'shrink'
12. Individuals who want to maintain the privacy of their
own personal information and / or affairs, such as
electronic diaries or personal journals whose
contents may prove embarrassing if left unprotected.
13. Computer users who routinely transmit and receive sensitive
information over insecure public communications channels,
for example, routine FAX MAIL, or E-mail
14. Information services such as computer bulletin board systems
who desire to maintain confidential member information
15. Writers who submit articles via electronic systems
16. politicians (the Watergate Hotel scandal)
17. any information which could reasonably be expected to result in, or
have negative connotations if it were disclosed to a general
audience, or at an inappropriate time.
18. negative credentials / reputation
Chapter Two
═════════════════
2.1 GETTING STARTED WITH THE DATA ENCRYPTION ALGORITHM
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
After you have uncompressed the DEA201.ZIP archive into a subdirectory
on your hard disk, you are ready to run the DEA and the associated
utilities. A suggestion is to create a DEA specific directory name such
as 'DEA201' and place all DEA files into this directory. Later when you
have become accustomed to the DEA, you may wish to add the DEA directory
to your PATH environment variable. This way you can have DOS find the
DEA executable files from any directory or drive.
2.2 INSTALL.BAT AND SETTING THE DOS PATH
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
If you would like to have all DEA related files placed into the
C:\DEA201 directory, you should run the INSTALL batch file. It will
copy all DEA files after they have been uncompressed, to the C:\DEA201
directory, where you will then be placed. The INSTALL program does not
automatically add the 'C:\DEA201' path to your PATH environment variable
as you may not have sufficient environment space available. Simply type
a semicolon (;) after the last PATH entry, and enter the path to the DEA
directory. Use the DOS SET command to view your environment variables,
if you don't know how your PATH is defined. Suppose your PATH variable
looks like this: C:\;C:\WRDPFT;C:\WINDOWS If you decide to add a path
for the DEA programs, you would issue the following command in full:
PATH=C:\;C:\WRDPFT;C:\WINDOWS;C:\DEA201<now hit enter>
^ ............type all this...........^
We placed a semicolon after 'WINDOWS', and added the path for the DEA.
When you wish to add other directories, you would place a semicolon
after 'DEA201' and follow this with the new directory. When setting the
PATH, you must type out everything from the left 'P' to the right '1'.
2.3 RUNNING THE DEA FOR THE FIRST TIME
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
If you are in the appropriate directory, you can now run the DEA by typing
its name, DEA <enter>. The DEA will display its sign-on banner along with
the program's usage syntax as follows:
The Data Encryption Algorithm, DEA Release v.2.01
Copyright (c) 1993 by Nellis du Maurier Information Security
All Rights Reserved
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Syntax: DEA {/I} [[/E] [/D]] /K[n] /OTP[n] in_file_name [out_file_name] [<R]
Cipher Directives: /E - encipher
/D - decipher
Operating Mode: /I - force interactive prompt mode <enter only: DEA /I>
Numerical Arguments: /K[n] - reference DEA key ID number [n]
/OTP[n] - select one-time-pad size: 1300 - 20,000
Files: in_file_name - must always be specified in full
[out_file_name] is optional for /E directive only
Redirection: <ASCII file containing path spec. to DEA.KEY file
Example: DEA /E /K5 /OTP7500 C:\BUSINESS\BIZ-PLAN.DOC C:\FAX_MAIL\MARSHALL.DEA
DEA /D /K1 /OTP3971 ISABELLA.DEA
The DEA always requires a minimum of four (4) command line parameters, or
one (1) when selecting (I)nteractive mode. Please note that the DEA will NOT
operate with PC XT class computing hardware. This includes the 8086, 8088,
and the NEC V20, and V30 chips. The microcode instructions within the file
DEA.EXE are designed for the Intel (tm) 80286 processor. All later Intel
processors such as the 80386, 80486, and Pentium (tm) have 80286 code
emulation; they can all run the DEA software.
2.4 LEARNING TO USE THE DEA VIA AUTOMATED BATCH FILES
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
The DEA software package provides several automated batch files along with
several .TXT files to allow you to test the DEA on files before you advance
on to your own files. This will allow you to learn the DEA command line
effectively and without fear of losing critical data. The batch (.BAT) files
are designed for teaching purposes, and if you are impatient to give the DEA
a whirl, then it is suggested you run them first, before you do anything
else. The batch files will only operate with files supplied with this
package; when you have mastered the DEA's command line switches, you may
delete them, or replace them with your own to allow you to automate your
daily information security chores. You may run the LEARN.BAT file to see
how the DEA handles file naming and the DEA command line format.
2.5 THE DEA COMMAND LINE SWITCHES
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
The DEA provides for seven (7) command line arguments, which are explained
next. Switches are case insensitive; you may use either uppercase or
lowercase, as you prefer.
/E - directive to encipher a DOS file
/D - directive to decipher / decrypt a DOS file
/K[n] - select DEA key identification number
/I - force DEA into (i)nteractive menu-driven mode
/OTP[n] - select one-time-pad size [n]: 1300 - 20,000
The first two commands are intuitive. The DEA's interactive mode is
activated from the command line by DEA /i, or DEA /I
If anything else is entered along with /I, it is ignored, and the DEA starts
in menu driven mode. Interactive mode is not used in the batch file
examples. If you experience problems with the DEA in command line mode, then
you still have this option available which should work.
The /K[n] switch specifies which DEA key will be referenced. Valid examples
are: /K1 or /K17, etc. There is no space between the 'K' and the number.
The command line switch /OTP specifies the size of the DEA's two internal
one-time-pads. The one-time-pad size can range from 1300 to 20,000 digits.
Any values outside this range will be rejected. The recommended range for
the one-time-pad size is 2,000 to 8,500. The reasoning behind these values
is time and user tolerance. Later, we shall discuss the technical
considerations involved in selecting the OTP values.
NOTE:
THE ABSOLUTE MINIMUM REASONABLE OTP VALUE IS 1,300. DO NOT USE ANY
VALUE LESS THAN 1,300.
Thus, in general, the DEA command line is as follows:
DEA /E /K3 /OTP2000 DIARY.TXT
This is the most basic format of the DEA command line. The proper ordering
of the commands must be observed, however. Note, also cases where you are
required to supply a numerical argument: /K[n], and /OTP[n]. Here, there
are no intervening spaces; that is, you must enter /K5 and /OTP2000, and not
"/K 5", or "/OTP 2000".
IMPORTANT NOTICE:
*******************************************************
* USE THE SAME OTP SETTING FOR BOTH /E & /D *
* *
* You must use the same OTP[n] value for encryption & *
* decryption, along with the same key ID number, *
* otherwise THE FILE WILL THEN BE LOST PERMANENTLY. *
* ----------- *
* THIS TRANSIENT ERROR NEED ONLY HAPPEN **ONCE** WITH *
* DEVASTATING CONSEQUENCES. *
* *
* ALWAYS check your DEA.LOG file FIRST if you are not *
* certain of the correct setting. This also applies *
* to the key ID number. Another tip here, is to make *
* a working copy of the DEA enciphered file first, *
* copying it to another directory to have a back up. *
* ....................................................*
* SERIOUS INFORMATION LOSS MAY RESULT WHEN THE DEA IS *
* PROVIDED WITH VALID BUT INCORRECT INFORMATION. *
*******************************************************
In interactive mode, you will be prompted for all the information the DEA
requires to process your request.
Following the /OTP[n] directive is the DEA input file name. This is the
file you wish the DEA to operate upon, either Encrypt, or Decrypt.
The [out_file_name], if given, is only used during encryption; it has no
effect during decryption. Note also that when decrypting, you must
specify the full file name including the file's extension, if any. For
example, "ARYAN.DEA", not just "ARYAN". The DEA makes no assumptions
regarding the input file's extension at any time.
NOTE: ********************************************************************
When selecting the /D (decryption) option, the DEA requires only an
input file specification, the output file path, if supplied, is
ignored. Instead, the output file path is stored within the DEA
file itself; you do not need to specify it explicitly; the original
file is restored to its exact same path location before encryption.
********************************************************************
Chapter Three
═════════════════
3.1 DEA DEFAULT FILE NAMING CONVENTIONS
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
The DEA allows the user two (2) options when choosing file names for output.
The user must supply the full name of the input file, while the DEA will
either default to its own file naming conventions, or will abide by the
user's file name choices. This default file naming applies only to the DEA
output file name. This characteristic behaviour is only active when the
DEA is placed into encryption mode from the command line. Below we shall
look at representative input and output file names.
input file name replaced with --> output file name
--------------- ----------------
1. D:\A04-1993.LB D:\A04-1993.DEA
2. JULIA.TXT (current directory) JULIA.DEA
3. C:\MEDICAL.TXT C:\MEDICAL.DEA
4. C:\WORK\SAMANTHA.TXT C:\TELEMATE\SEND\SAMANTHA.MSG
5. C:\JUNK (file name, not directory!) C:\JUNK.DEA
6. D:\PLAN.DOC C:\BUSINESS\MARSHALL.PRV
In general, if the input file is a valid DOS file path, then the
file path will be used for the output file path with the extension '.DEA'
if only the input file was specified. (1,2,3,5) In this manner, the input
file is replaced with its enciphered equivalent.
If the input file does not contain an extension, the extension '.DEA' is
appended to the file name if only the input file was specified. (5)
If the user supplies both an input file name and an output file name, then
the DEA will use the user's file specification. This is known as user
priority file naming. In this case, if the input file name does not contain
a file extension, then none is appended, as the user has supplied his / her
own output file name, the DEA will use the user's file name specification.
Even if the input file contains an extension, the output file may or may not
contain any extension; this depends entirely upon the user's output file
specification. (4,6)
It will be helpful to remember that DEA files need not necessarily have the
extension '.DEA'. You can direct the DEA to create any file name you wish
for the DEA output file. This is the reason why the DEA makes no assumptions
about the input file name. However, for consistency, you should adopt this
practice. If you prefer to specify only the input filename, then the DEA
will always give the file the '.DEA' extension. This applies only to DEA
command line usage, not to interactive mode. When the DEA is used in
interactive mode, and decryption has been selected, the DEA will not query
for the output file name, as the output file name is stored within the DEA
enciphered file, this name will be used.
Note that file conflicts and information loss may result when an input file
name's extension is '.DEA' and the DEA is enciphering and the output file
name will have the '.DEA' extension also. This is an obvious name conflict
of which you should be aware. The DEA does not check for these subtle
potential errors, it is your responsibility.
3.2 DOS FILE TYPES & FILE ATTRIBUTES
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
The DEA can operate upon any type of MS-DOS(tm) file. All files may be
categorized into two main types: ASCII and binary. The DEA operates with
all files, regardless of type.
DOS files may have one or more file attributes set. The DEA will terminate
only if the READONLY attribute is set. If the input file is hidden, or has
its system attribute, or both set, the DEA will accept the file, provided
that the path to the file is indeed valid. However, with files who's
attributes set as such, the DEA output file will not have these attributes
set and will, therefore, be displayed by the DOS 'DIR' command.
3.3 THE DEA.KEY FILE LOCATION ERROR
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
The DEA key design minimizes TEMPEST attacks via the manual typing of the
key during encryption or decryption. The operator is also prevented from
discovering the actual key data by usage of the DEA key ID number. The last
concern regarding key security, is keeping the key(s) physically away from
the computing equipment. The only time the DEA key should be available to
the program(s) is when they are required. While this may not be completely
convenient, the DEA provides every reasonable avenue to allow the programs
to access the key file. All these methods encourage users not to store the
DEA.KEY file within their computers. The DEA provides for a number of
different methods of accessing the key file as discussed below.
If the DEA cannot locate the DEA.KEY file, it will display an error message
without terminating. This is a serious error, however the DEA will prompt
the user for the path to the DEA.KEY file. If this situation arises, you
should enter the full path to a known drive and / or directory plus the name
"DEA.KEY" for the file name where this file normally resides. If the path
is still incorrect, then the DEA will terminate.
This error occurs most commonly when the user moves about in the directory
tree and invokes the DEA from a directory other than where all DEA specific
files are located. If you have set your PATH environment variable to allow
DOS to find your DEA files, you may then invoke the DEA from any directory
or drive, but the DEA will not successfully locate its key file, as it looks
only on the current directory. This may prove cumbersome at times, as it
interferes with automated DEA batch procedures. The basic thing to remember
about the DEA.KEY file is that regardless of where you are in your directory
tree, the directory you are currently in when you invoke the DEA, is the
directory scanned for the DEA.KEY file. However, there are several ways in
which this situation can be remedied as follows:
1. place all DEA files in a directory such as C:\DEA. Now, whenever you
want to employ the DEA, move into this directory, either by hand, or by
a batch file to help avoid the tiresome DOS path typing. Once in the
directory, use the DEA as you normally do.
2. As above, but the C:\DEA directory does not contain the DEA.KEY file,
instead, the file is located on a removable floppy drive A:\, or B:\.
Assuming your PATH is set so that DOS can find your DEA executables, you
would now go to drive A: for example, and invoke the DEA. The DEA will
load from the C:\DEA directory, but because you are now on drive A:\,
the DEA will search the A:\ root directory for the DEA.KEY file. Since it
is indeed there, the DEA will operate normally.
* This method is preferable because it involves physical security directed
over the DEA.KEY file, that is, the DEA keys are not physically to be
found in your computer system, they exist separately and outside the
system. This is called Key Management, and is a very real concern for
serious computer information security.
3.4 ADVANCED METHOD OF LOCATING THE DEA.KEY FILE
VIA THE DOS REDIRECTION PIPE
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
This method is preferable over the two methods outlined above as it is able
to maintain discreet key management along with automated DEA batch file
operations. You will find this technique very helpful in keeping the DEA.KEY
file out of your computer system, and thus greatly enhancing your overall
information security. Below, we discuss the DOS redirection method and then
illustrate several DEA command line examples:
DOS redirection symbol used: < meaning information coming into a program
Suppose, you wish to have the DEA.KEY file reside on a 1.44MB floppy disk and
you want the DEA to be able to locate this file without explicitly
instructing the DEA where to find it each time you run the DEA.
step 1.
Create an ASCII file, preferably on your hard disk, say the root
directory like C:\ for example. From DOS, give this command:
copy con DEA_PATH
step 2.
what we want to do now is to create a file which contains a DOS
file path to the DEA.KEY file. Since we decided that we want the
key file to be on the root directory of drive A:\, we type in:
"A:\DEA.KEY" (do not put the quote marks when you actually do it)
step 3.
Press F6, you will see ^Z, then hit <enter>
We have now created a file named DEA_PATH on the root directory of drive C:\
which contains the ASCII text: "A:\DEA.KEY" (no quote marks!).
Of course, the file name DEA_PATH is just for illustrative purposes here, you
could have chosen a name such as "DP" only, the shorter, the better, as it
saves keystrokes if manually entering the DEA command line. However, it is
suggested, you use the name DEA_PATH, to easily remember it. Also place this
file on the root directory of your hard disk where it can be most certainly
found by the DOS PATH variable. If you are using a word processor, then save
the "A:\DEA.KEY" text to an ASCII file, that is, without control characters
and such.
And now, lets see how we use this redirection in a real DEA command line,
remember that you are now out of the DEA directory, the DEA directory does
not contain the KEY file, it is on the root directory of drive A:\. However,
DOS can find your DEA executables, therefore we issue such a command as the
following:
1. DEA /E /K2 /OTP1993 C:\JULIA.TXT <C:\DEA_PATH
2. DEA /E /K2 /OTP1993 C:\JULIA.TXT B:\LETTERS\TO_SEND\LOVE.DEA <C:\DEA_PATH
3. DEA /D /K2 /OTP1993 C:\JULIA.DEA <C:\DEA_PATH
----------------------------------------------------------------------------
{switches} {input} {output file path} {redirect}
-optional-
first second third last
The DOS redirection symbol '<' and the directive '<C:\DEA_PATH' must be the
last command on the command line (either from DOS, or in a batch file).
The <C:\DEA_PATH tells the running program to use the information in the file
DEA_PATH for the program. Note that you must specify the path (C:\) to the
file DEA_PATH, otherwise this will not function. Therefore, to use DOS
redirection, the following conditions must be satisfied:
1. an ASCII text file containing only a DOS file path like C:\DEA.KEY, or
C:\NELLIS\DEA.KEY, or A:\MARSHALL\DEA.KEY
2. when you use DOS redirection, be sure to tell DOS where to find the file
say, DEA_PATH which contains the actual path to the DEA.KEY file itself.
3. lastly, the DOS path specified in the file DEA_PATH must actually be
valid and contain the file DEA.KEY
**************************************************************************
Redirection Format & Command Synopsis
-------------------------------------
<C:\DEA_PATH - last command on the DEA command line
< - the DOS redirection symbol, information going into a
program
C:\ - tell DOS where to find the file being redirected
DEA_PATH - ASCII file containing file path directive to the DEA.KEY
file
**************************************************************************
This method should be preferred if you are using the DEA in a serious
information security environment. Note, however that some DOS shell programs
which allow other programs to be run from within an environment, may not
work correctly when used with DOS redirection pipes in this manner. Note
also that the file DEA_PATH, or whatever name you choose to give it, can
contain only one file pathname specification to the DEA.KEY file itself.
The DEA will not function correctly when the DEA is used in interactive mode
along with DOS redirection, that is, the command DEA /I <C:\DEA_PATH
will bring up the DEA interactive screen logo, but will seem to lock up. It
is actually not locked up, only that the redirected information is
interfering with the console (keyboard) programming. If this happens, simply
press CONTROL-BREAK together and that should return to the DOS command
processor level.
Note that with redirection, you are obliged to specify a file which
contains the actual path designation to the key file; you cannot simply
specify a plain DOS path to the key file itself, as in: "<C:\DEA.KEY", or
"<A:\DEA-KEYS\DEA.KEY"; these ASCII file paths MUST RESIDE IN A FILE.
3.5 MAKING THE DEA.KEY FILE READONLY
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
You may want to make the DEA.KEY file READONLY to protect against erasure.
If you do, you should be aware that the GenKey utility will fail to operate
properly when it attempts to append another key to the file. You could
circumvent this problem by temporarily removing the READONLY attribute,
running GenKey, then restoring the READONLY attribute when you are finished
with GenKey.
The DEA will not function correctly if the DEA.KEY file is made hidden and
you use the redirection symbol. The problem here is because the file is
hidden. In this case, the DEA will stop and ask for the path to the DEA.KEY
file, so the hidden attribute on the key file should not be used when it is
desired to use the DEA with automated batch processes; it will still work,
but its operation will be interrupted.
Creating multiple working copies of the DEA.KEY file is not recommended
as it may result in serious information loss and security breaches; ONLY
make back-up copies to either, or both floppy diskette and paper.
3.6 THE DEA EMBEDDED FILE PATH
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
The input file path to the DEA in either command line or interactive mode is
embedded in the DEA file so that upon decryption, the original file name
along with that file's original contents are completely restored. This
design is more than intuitive, it is a great convenience. However, in some
cases, the embedded file path may cause some minor problems. If, for
example, you have just completed encoding a file and it contains a DOS path,
and you now send this file to a friend, your friend's directory tree will
probably be different from yours, and thus when he attempts to decrypt it,
the DEA terminates, complaining about a non-existent directory path. Here,
the DEA is attempting to restore the original file from your directory, to
the same directory in your friend's directory structure, but he doesn't have
that directory. There are three ways to deal with this. First, your friend
may decide that he will just create the required directory, and then try the
decryption again. He can also go into the encoded file and eliminate the
DOS path specification, keeping just the file name itself. Eighty one (81)
bytes of any DEA file contain DOS path and file name information, and may
be altered at will, provided that nothing beyond the initial 81 bytes is
altered, and that the DEA file is saved with no size modifications. The
third method of avoiding this minor problem, is to go directly to the
directory where the file you wish to encrypt resides, and invoke the DEA at
this directory. Or, copy the desired file to the directory where you are
now, and then start the DEA to avoid having the DEA include a full DOS
subdirectory path. In this way, when the file is deciphered, it can be
placed onto any directory or drive.
This release of the DEA does not store the time and date stamp of the
original file.
3.7 DEA AUTOMATIC PROCESSING FILE CLEAN-UP
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
W A R N I N G:
The DEA completely and permanently erases all input files when the
DEA is used in Encryption mode. Although data loss is very unlikely
to happen, it is possible, and users should be aware that the DEA
will never 'forget' to erase PERMANENTLY and COMPLETELY all traces
of the input file when encrypting.
The DEA will always 'clean-up after itself'. It will not leave any traces
of the original plaintext on the disk media. When decrypting, the encoded
file is simply removed by deleting the file's DOS File Allocation Table (FAT)
on the current directory only. After encryption, the DEA automatically
engages the Military File Deletion algorithm; you will be alerted to this by
the audible beeps. The MFD algorithm completely overwrites the original file
a total of ten (10) times with an alternating bit pattern. This is nine (9)
times more than any other software crypto program would do, and users of the
DEA can feel assured that even if their harddisk were sent away to a special
data recovery laboratory, there would be no incriminating data to salvage.
The MFD algorithm in the DEA is also provided as a stand alone utility
(MFD.EXE) so that you can completely and permanently eliminate the data files
you don't wish to keep around, without having to run the DEA just for this
task. Note that the MFD can also be used with this intention to kill virus
infected files so that those known infected files do not add more infection.
3.8 THE DEA LOG FILE
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
The DEA automatically creates an new DEA.LOG file in the current directory if
none exists, or updates it if it does exist. If you invoke the DEA from
several different directories, you will find that these directories contain
DEA.LOG files. To avoid this problem, always invoke the DEA from a standard,
consistent directory.
The LOG file itself contains some data pertaining to decryption,
specifically, it contains the OTP settings used for various files plus key
ID numbers. This information should be maintained discreetly, just as the
key. It should, perhaps, be on the same floppy as where the keys reside.
You could have a floppy disk (suggested 1.44MB) with a DEA_KEY subdirectory,
along with a DEA_LOG subdirectory on the same floppy. At the end of every
month, you could edit the file, deleting log entries which are no longer
significant.
Another DOS redirection trick works for multiple DEA.LOG files scattered
about in different subdirectories. Suppose you decide that your main DEA.LOG
file will be kept in C:\DEA. However, you see from the DEA.LOG files that
there are log files all over, how can you put all of them into one convenient
holding place? Regardless of which directory you are in, after the DEA
shuts down normally, the subdirectory will contain either a new, or updated
DEA.LOG file. Now issue the following DOS command:
type C:\WINDOWS\DEA.LOG >>C:\DEA.LOG
Usually, the 'type' command will output a file to the screen, but here, the
effect is to append the DEA.LOG file in the C:\WINDOWS subdirectory to the
already existing DEA.LOG file in the C:\DEA subdirectory. You may now safely
delete the C:\WINDOWS\DEA.LOG file knowing that its contents have been
appended to the end of the DEA.LOG file in directory C:\DEA. Of course, the
C:\DEA.LOG file will get larger as this is done over time, but it keeps things
organized and documented. Remember to use '>>' here, not '<' as we did
earlier on the DEA command line. '>>' will, append data, while '>' writes a
new file, destroying the older version. You can also create an automated
DEA batch process using DOS redirection to take care of daily DEA.LOG files.
As mentioned previously, you should also make an effort and get into the
habit of backing up the DEA.LOG file. Your firm's Information Security
Officer should have close control over the DEA.LOG file. It not only serves
to record a DEA 'transaction', but it also contains confidential DEA related
records pertaining to each transaction. This is fairly simple to do, and
once it is set up as an automated batch process, it is routine and
effortless. DOS redirection pipes can be a great benefit here, as they will
help to keep things organized and documented at all times.
3.9 THE DEA KEY FILE
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
To use the DEA, you must have a valid DEA.KEY file. As noted, there are
several methods available for you to address this file when using the DEA.
The DEA is shipped with one DEA key in the DEA.KEY file. The key itself is
180 bytes long, but the actual size of the key file is 240 bytes, the
remainder is used by the DEA during processing. With the addition of new
keys, the key file will grow by 240 bytes each time, that is 240, 480, 720,
960, 1200, 1440, 1680... The DEA performs a check to make certain that the
key file is indeed a multiple of 240. If not, then the DEA will terminate.
The total number of keys available is computed thus: DOS reported size of
file DEA.KEY is: 2160 bytes. Now, 2160 divided by 240 gives 9. Therefore
there are 9 keys available. The total number of keys the DEA can address is
32,767. This means that if your DEA.KEY file's size was 7,864,080 bytes in
length, then 7,864,080 / 240 = 32,767 total keys available.
It is strongly suggested that you physically keep the DEA.KEY file away
from your computer system. Instead, the key file should be backed up to at
least two (2) floppy disks, one for daily use, the other serving as protected
archive back up copy. A typical 1.44MB floppy disk is very convenient for
this; it will be capable of storing approximately 6,141 DEA keys.
The DEA v.2.00 does not keep the DEA.KEY file open as it does with other
processing files, instead, the DEA will: <1> scan current or specified
directory for the file DEA.KEY, <2> open the file DEA.KEY, <3> read the
indicated key via the key's ID index, <4> store the key data in internal DEA
data structure, <5> close the DEA.KEY file. At this point, the user can
safely remove the floppy DEA key diskette from the drive; the DEA will never
again need to reference the key file during that session. At the conclusion
of the encryption or decryption session, the DEA will automatically delete
the contents of the internal DEA key data structure. This assures you that
there are no keys or parts of keys floating about in your PC's memory before
powering down the system.
The name of the key file DEA.KEY must not be changed, since this unique name
is encoded into the DEA and the DEA utilities, with the exception of MFD.EXE.
3.10 VALID DEA KEYS
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
All keys produced by the GENKEY utility are valid. In cases where the user
invokes GENKEY and does not provide all information requested by GENKEY, then
GENKEY may or may not terminate with a divide by zero runtime error. Here,
the user has not specified all initial prime divisors, but GENKEY has opened
the file DEA.KEY data file. If the file is a new one, it has an entry in the
DOS File Allocation Table (FAT), but has size zero (0). If the DEA.KEY file
already exists and GENKEY terminates with a run time math error, then no
data in the DEA.KEY file is disturbed. Note that you cannot use a DEA.KEY
file of zero length for obvious reasons.
If the user wishes to quickly go through all of GENKEY's numerous information
prompts, without actually entering "real" data, then GENKEY will still
create a DEA.KEY file, or update an already existing one. But, if you
carefully examine the newly created key with the KEYVIEW utility, you will
see that typical DEA key information is missing; normally this is shown by
zero. If such a "valid" key is used with the DEA, the DEA will terminate
with a divide by zero math run time error because the DEA is unable to
correctly build the two critical one-time-pads for the system. In general,
you can be assured of valid keys at all times if you truthfully supply
GENKEY with 'real' and valid data as GENKEY requests.
As noted in the section THE DEA AND DATA CORRUPTION, the data in the DEA.KEY
file may itself become corrupt somehow and will, therefore, result in an
invalid key. Please refer to that section for tips and general guidelines
to follow which will make your DEA experience a safe and productive one.
Another important note regarding validity of DEA keys is the following. The
values specified for the denominators should not be excessively large; they
should not be larger than 429,496,729 - 20. Values larger than this
value will cause unpredictable results when the DEA is engaged in the
production of the two internal one-time-pads. Specifically, this
relates to the DEA's mod-mult random feed algorithm.
Please note that the DEA does not store any key information within a DEA
enciphered file. As a result of this, the DEA program cannot verify keys for
you. You can achieve this effect, if you so desire, for periodic key
changes via an embedded ASCII Key Change Packet which we shall discuss.
This practice in no way reduces the security of the DEA, and is strongly
advised to change keys on a periodic basis with all cryptographic tools.
As the DEA provides an extreme level of security, the hassle of changing
keys frequently can be minimized to a bi-weekly or month-end affair.
If the encryption key(s) were embedded in the cipher file, then it would be
possible to verify the key by both the program and some attacker wishing to
gain access to your data. Some programs have this "feature" built in, but
it is not advisable because it represents a serious security breach. With
such a situation, the attacker is fully justified in attempting to discover
the embedded key from the enciphered file, rather than expending his effort
going through 72 quadrillion key combinations. Such encryption tools are
nothing more than a plaything; any real security provided by such intuitive
design is quickly negated by the strategy of encoding the key into the file.
The DEA data encryption package is designed to provide serious information
security, not to seriously jeopardize your confidential information. Thus,
this capability will never be incorporated into the Data Encryption
Algorithm Software Package.
Note that DEA keys are 'verified' transiently: if the correct key plus the
correct OTP plus the correct DEA ciphertext is submitted to the DEA, and
the program produces the anticipated output, then all key information has
been verified and there was no corrupt data.
Chapter Four
═════════════════
4.1 THE DEA ONE-TIME-PAD SIZE SETTING AND INFORMATION CONTENT
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
The DEA always requires an OTP value, either for encryption or decryption.
This value will greatly affect speed performance tests. In general, the
larger the value, the slower the DEA will operate. Although you may specify
a numerical argument for /OTP[n] in the range 1300 to 20,000, it is best to
select an OTP value, for example, which results in a 70 - 30% mix of Stop
Addresses to scrambled 8-bit bytes. The IBC counter from command line usage
shows the number of scrambled 8-bit bytes (in the form of 16-bit integers)
in the DEA ciphertext.
This OTP value directly influences the nature of the DEA ciphertext's
information content. During command line encryption, the DEA shows two
counters, the IBC counter indicates the number of information bits from
plaintext to ciphertext. Most cryptographic software tools, including the
DES, will have a 100% information bit count in the ciphertext. This means
that if the plaintext consists of 80,000 bits (10,000 bytes), then there
are also 80,000 bits of information in the ciphertext (without compression).
Although the 80,000 bits are scrambled via the agency of some algorithm,
there are, nonetheless, 80,000 bits of actual information in the ciphertext.
Cryptographic weaknesses will usually be exposed when a cryptanalyst is
engaged in the task of examining the transformations when a chunk of
plaintext is exposed to the action of a particular cryptographic algorithm.
The DEA Cipher Function v.2.00 was designed with the main goal of eliminating
the plaintext-to-ciphertext information bridge. The 'bridge' may be thought
of as the particular algorithm shuffling the bits in the plaintext to produce
the ciphertext; the bit shuffling logic of the algorithm is the bridge. The
cryptanalyst's job is to traverse this bridge with an information gap with
the aim of using the ciphertext's information bit content to reverse the
logic of the algorithm. In other words, the cryptanalyst is trained to seek
out the very minute patterns of order in an otherwise entropic environment.
The DEA v.2.00 has the capability of squeezing out 99% to 100% of all
plaintext information bits. The result of this process, is ciphertext which
contains nearly zero shuffled plaintext information bits. There are also
other algorithms which have this unique ability to eliminate information
bits while replacing them with algorithm dependent output. The RSA is one
other such algorithm. With such ciphertext, the cryptanalyst is forced to
dispense with a good portion of her / his professional training, and is thus
manoeuvered into the position of examining the operating characteristics of
the algorithm in question.
For most information security applications which the DEA will be called upon,
it is not necessary to select the maximum one-time-pad size of 20,000 digits.
It would be more practical to select a value between 2000 and 10000.
Basically, the faster your Personal Computer is, the larger the OTP settings
you can select.
It is important to realize that in the majority of cases, the DEA will
produce 'mixed' ciphertext. That is, the ciphertext will consist of Stop
Addresses along with shuffled plaintext information bits of a variable
percentage, depending upon the OTP size setting.
There is no real or apparent difference with regard to security provided by
the DEA with smaller or larger OTP settings because the DEA's Cipher Function
is not strictly defined to operate in a particular manner; the definition
incorporates the overall design, but allows flexibility based on the OTP
size variable. Furthermore, both the Cipher Function and the one-time-pads
operate on a random basis, not pseudorandom. Of course, the design imposes
mathematical limits, but this has no effect on security provided by the DEA.
IMPORTANT NOTICE:
*******************************************************
* USE THE SAME OTP SETTING FOR BOTH /E & /D *
* *
* You must use the same OTP[n] value for encryption & *
* decryption, along with the same key ID number, *
* otherwise THE FILE WILL THEN BE LOST PERMANENTLY. *
* ----------- *
* THIS TRANSIENT ERROR NEED ONLY HAPPEN ONCE WITH *
* DEVASTATING CONSEQUENCES. *
* *
* ALWAYS check your DEA.LOG file FIRST if you are not *
* certain of the correct setting. This also applies *
* to the key ID number. Another tip here, is to make *
* a working copy of the DEA enciphered file first, *
* copying it to another directory to have a back up. *
* ....................................................*
* SERIOUS INFORMATION LOSS MAY RESULT WHEN THE DEA IS *
* PROVIDED WITH VALID BUT INCORRECT INFORMATION. *
*******************************************************
4.2 THE DEA UTILITIES - GENKEY, KEYVIEW, MFD
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
The DEA Software package includes three (3) utilities to help you to use the
DEA effectively. The GenKey utility generates new DEA keys for use with the
DEA program. GenKey requires a full pathname to the DEA.KEY file on the DOS
command line. Invoking it without a valid pathname produces an error
message and GenKey will terminate. You may specify a pathname to any valid
drive and directory. Suppose you have a key file located on C:\DEA. Thus,
if the following GenKey command line is given:
GENKEY C:\DEA\DEA.KEY
GenKey will append a new key to the DEA.KEY file in directory C:\DEA.
If, however, you specify a valid path, but there exists no DEA.KEY file
there, then GenKey will create a new DEA.KEY file in the specified directory.
Suppose for example, you issue the command:
GENKEY A:\DEA-KEYS\DEA.KEY
GenKey will scan the directory A:\DEA-KEYS for the DEA.KEY file. Since there
is no such file there, GenKey will create the DEA.KEY file on drive A: in
subdirectory DEA-KEYS.
If GenKey is given a pathname which does not exist, GenKey will terminate,
that is, GenKey will not create the directory if it does not already exist,
you must create the desired DOS directories first. In general, if you
specify a valid DOS path (with "DEA.KEY" at the end) GenKey will append a
new key if the file DEA.KEY already exists in the specified path, or if the
file pathname is valid, but there is no DEA.KEY file there, then GenKey will
create a new DEA.KEY file in the specified path.
Although the GENKEY procedure could have been automated via the use of a
random number generator (PRNG), there is a subtle and unobvious reason why
this strategy was not implemented. Refer to the APPENDIX for a full
discussion of this issue.
The KEYVIEW utility is designed to allow you to have a hardcopy of any key
residing in the DEA.KEY file. Again, you must provide KEYVIEW with a valid
path to the DEA.KEY file on the DOS command line at the time you invoke
KEYVIEW. The KEYVIEW command line format is exactly the same as that for
GenKey. KEYVIEW will not write anything to the DEA.KEY file, instead, it
will write to a file called DEA_KEY.ASC. This file will contain the ASCII
textual equivalent of the key's ID number. You may then print this key, or
store it in some other manner as you desire.
If you have several keys in the DEA.KEY file, and you want to have the ASCII
equivalent of all of them, then you must run KEYVIEW several times, each
time selecting a higher key ID number (keeps things ordered). All output
from the KEYVIEW utility will be placed into the file DEA_KEY.ASC.
The file DEA_KEY.ASC will be written on the current directory.
Remember that secrecy must be applied to the file DEA_KEY.ASC as it contains
actual key(s); it is just as important as your DEA.KEY file itself! It is
suggested that after you have printed the contents of DEA_KEY.ASC, or have
added it to a key notification change packet, you should then run the MFD
utility to remove all traces of DEA's key information from the DEA_KEY.ASC
file; there are many subtle little gaps which can occur and may severely
jeopardize your information security.
The MFD utility is a small handy delete utility. Be advised, however, that
MFD will permanently, completely, and irrevocably delete the file. The MFD
algorithm is also used in the DEA. After encryption, the DEA invokes its
own internal MFD algorithm. The MFD overwrites the input file with an
alternating bit pattern a total of ten (10) times before finally removing
the file from the DOS File Allocation Table (FAT). If you have several
copies of a file in different directories, and you use the MFD to erase one
of those multiple files, then only the one specified by you will be erased;
the other copies will be not be touched. The MFD utility does not accept
DOS wildcard characters; it is designed to operate upon one file at a time
only. This is to avoid a potential data loss catastrophe.
MFD also requires a file path given on the command line, for example:
MFD C:\JUNK.TST
MFD LETTER.RYN (current directory)
MFD will seem to take a rather long time to delete a file from a floppy
disk; this is normal as floppy drives are many times slower than hard disks
or ram disks. If your drive light is on, don't worry, MFD is operating
as usual, as long as you also see the indicator changing, and MFD beeps
occasionally, everything is fine.
4.3 SECURE TRANSMISSION OF KEYS
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
The KEYVIEW utility is also provided with this package to allow you to have
a hard copy of the DEA.KEY file, or a particular key that you desire to
communicate to an associate or friend. How you go about this is up to you.
You may want to encode the ASCII textual equivalent of, say, key ID #7 into
a DEA file which you will transmit either in person, or by modem to the other
individual. Suppose you have some text file called THE_BOSS.TXT. You and
your acquaintance are assumed to be already using a DEA key which is the
same for both people. However you want to signal to your friend, that on
the date (x), the following DEA key will go into active service for
a total of thirty (30) days thereafter. At the end of the file THE_BOSS.TXT,
you would make a note of this changeover. For example, create a file with
the contents shown below:
*******************************
* DEA Key ID Change *
* *
* From: J. Francis *
* To : R. MacPherson *
* *
* Date: 09-23-1994 *
* *
* Invocation Date: 10-01-1994 *
* New DEA Key ID: 1 *
* New OTP: 5357 *
* Expiry Date: 10-31-1994 * <---- file name is: KEY_PAK.ASC
* Shipping Date: 09-29-1994 *
* *
* ASCII DEA key shown below *
* *
*******************************
Issue the following DOS command in full:
type KEY_PAK.ASC >>THE_BOSS.TXT
This will now append the above contents of the file KEY_PAK.ASC to the end
of the file THE_BOSS.TXT. But, J. Francis not only wishes to advise his
acquaintance of the new key, but also wants him to have the new key in
ASCII format.
Therefore, J. Francis will need to created a new DEA key with the GenKey
utility which will be placed into the file DEA.KEY. J. Francis must now
extract the new key with the KEYVIEW utility. He can now issue the DOS
command to add the contents of DEA_KEY.ASC to the end of the file
THE_BOSS.TXT as follows:
type DEA_KEY.ASC >>THE_BOSS.TXT
J. Francis can now encipher the file THE_BOSS.TXT with his previous key (not
the new one, just yet!) and send it to R. MacPherson. When R. MacPherson
receives the file from J. Francis, he can decipher it with their previously
mutually agreed upon DEA key. R. MacPherson, on the invocation date, will
be required to use the GenKey utility and feed it the new key information
J. Francis has outlined. Observe that both the key and the OTP setting
together, are required for successful decryption; the OTP value is indeed
key information.
This is all relatively simple, but it is advisable to treat all your DEA.KEY
files with respect; normally, new keys are added to the DEA.KEY file by
GenKey, to avoid having multiple key files scattered across different
directories. With the KEYVIEW utility, you can extract only the specific
key you desire to have encoded into a message, like the example given.
Caution is advised only in situations where there are multiple DEA.KEY files,
for obvious reasons. It is strongly suggested that you avoid multiple key
files; this situation can quickly become a terrific headache and even result
in very serious data loss.
4.4 THE DEA AND PRIVATE E-MAIL
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
The DEA ciphertext cannot be transmitted through electronic mail channels.
This also applies to the majority of cryptographic programs because all
eight (8) bit permutations are used. E-mail communication channels typically
employ a limited ASCII character set which can be sent reliably over diverse
networks such as Internet, Compuserve, and others.
DEA users who wish private E-mail are directed to employ the UU-encoding, or
XX-encoding system. These coding utilities can be used to encode any type
of file into a standard ASCII limited character set which can then be sent
with reliability over diverse information networks.
The XX and UU-encoding strategies will expand the plaintext (whether it is
a DEA output file, or otherwise) by 33%. You can use any files with these
programs.
These utilities may be obtained from various Bulletin Board Systems (BBS's)
and are not provided in the DEA software package.
Note that both XX and UU-encoding are good for this purpose, but corrupted
data may still occur with the encoded file. Such problems may be transmitted
on to the DEA file itself when the file is decoded first by UU-decode at the
receiving end.
If you are concerned about the expansion of text with these utilities, you
may wish to consider compression. For example, your private E-mail can be
FIRST compressed, SECOND DEA encoded, THIRD UU-encoded, then SENT as E-mail.
To function correctly, both the sender and receiver must use the following
coding sequences:
sender: 1. compress plain message
2. DEA encode the compressed file from step #1
3. UU-encode the DEA enciphered file from step #2
4. send the UU-encoded file as E-mail
receiver: 1. UU-decode the E-mail
2. DEA decode the output file from step #1
3. uncompress the file from step #2
4. read your E-mail message
Note that as there are several 'layers' of coding involved here, even a
single corrupt bit in the final UU-encoded file may upset the other layers,
resulting in gibberish. Users will have to experiment a bit first to
determine if these utilities can be used in your situation with reliability.
In general, if your communications are reliable, then you can use these
methods with no difficulties.
DEA enciphered files can be electronically transmitted with your
communication program just like any other files. For example, a book
author like the TV character Jessica Fletcher of "Murder She Wrote" fame,
may decide to encode the final manuscript with the DEA and transmit it to her
publisher. There are no restrictions with transmission of DEA files. The
restrictions apply only to electronic mail systems with abridged character
sets.
There are no restrictions in using the DEA encoded files with your FAXCARD.
4.5 DEA CIPHERTEXT CORRUPTION
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Any information in a digital device can become corrupted. If the device is
'smart' and contains an error correcting algorithm, data corruption may or
may not extend to the encoded instructions responsible for error correction
itself. Thus, the term "Error Correction" does not imply 100% safety.
The DEA v.2.00 does not apply error correction strategies to the decryption
process. Modern day computer data storage media are very reliable. It is
advisable, however, to always choose brand name floppy disks; no name disks
are actually thinner in diameter and will wear faster. Such disks are not
manufactured to the same precise and exacting standards set by well known
manufacturers.
Any computer file can become corrupted by many different causes: hardware
controller failure, media failure, dust, radiation, magnetic fields, plain
wear-and-tear, computer viruses, etc.
If DEA ciphertext is corrupt, the DEA has no way of knowing this fact. It
will process the file with the given key information as usual. If the
deciphered file reflects a compressed file, the compression utility will
report an error. If the file is an ASCII file, it may not be intelligible.
If the file is an executable file, it may not function correctly, or may
even hang the computer. When such a problem arises, you will know that the
data is corrupt and you should have a close look at possible hardware
problems, storage media reliability, and physical media handling and storage
practices.
Many people operating Personal Computers routinely place their floppy disks
beside or leaning against their monitors. This practice, although it may
be convenient, should be discouraged. Further, keep important floppy disks
away from other magnetic office equipment such as the microphone of
telephones. Stringent physical handling and physical storage guidelines of
floppy disks should be maintained at home and the office. Information loss
need only occur once to remind you that an ounce of prevention is indeed
worth a pound of cure. And, in a business environment such careless
treatment of floppy disks and their contents may prove embarrassing, time
consuming, may result in lost profits, and even in your job. Therefore, if
disks are accorded their due respect, then you should not have to worry
about data corruption with the DEA. Always perform routine data media
maintenance and back up on a regular basis as your electronic information
volumes dictate.
Data corruption can be of varying degrees of severity. If data is corrupted
at or near the beginning of the enciphered file, then all or most of the data
is lost permanently. If the data corruption begins at the half way mark of
the file, then the last 50% is lost. In general, the point at which
corruption begins, is the point at which data is irretrievably lost. Data
corruption may also be sprinkled throughout the file in a random manner, in
which case, data from the first corrupt data byte to the end of the file is
lost permanently.
With corrupt ciphertext, the DEA is unable to maintain its correct Cascade
Synchronization. This is not a fatal program error but is a fatal
information recovery error. And, as noted, the DEA does not check for this
error, nor report it. As soon as this internal Cascade Synchronization is
disrupted by corrupt DEA ciphertext, the entire delicate balance of the
system is completely and irrevocably altered, and the DEA is forever unable
to recover thereafter.
It should be noted that all computer programs worth their salt which work
with data files will not cause data corruption by themselves, data corruption
is almost always traceable to a non-program cause, unless the program in
question is a computer virus embedded within a program itself, in which case,
the cause is still external to the program being used. Caution is advised
in multi-tasking environments, as switching back and forth between programs
may cause cross linked files.
Chapter Five
═════════════════
5.1 THE OPERATING SYSTEM
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
The DEA v.2.00 was designed to operate under the MS-DOS(tm) operating
system version 4.01+ for personal computers. You may be running the DEA
from WINDOWS(tm), DESKVIEW(tm), OS/2, or in a network environment. While
the DEA has been designed and tested under DOS 4.01, its operating
characteristics, especially the DEA's redirection, may not work completely as
documented in these other operating environments. Check your operating
system's documentation first, if you are having difficulties.
The DEA keeps a number of files open during processing, these files are:
1. the input file
2. the output file
3. the .LOG file
*** the DEA key file is opened, read, and then closed at the very start
of the program, so that you may remove the diskette containing the
key information immediately following normal DEA processing.
In multi-tasking environments, keeping a number of files open, then switching
to another program with its own set of files, and then going back and forth
like this, may end up in cross-linked files. Excercise CAUTION AND BACK-UP
your DEA.KEY file to a floppy diskette in both binary and ASCII forms.
If you intend to run the DEA under other operating systems, a suggestion is
to run the LEARN.BAT file first and observe the behaviour of the program.
If everything works fine, then you may try redirection pipes next and see if
this works as it should.
Consult your Operating System manual if you are running the DEA in a multi-
tasking or network environment regarding multiple open files.
5.2 DATA SAFEGUARDS AND THE INTEGRITY OF DATA
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
The DEA was designed so that when a file is to be enciphered, its
corresponding plaintext equivalent is automatically and completely erased,
thus replacing the original with an equivalent file, except that the new
file has a 'lock' on it. All that encryption can provide is a 'lock' for
the information. We lock our cars, houses, safes, diaries, etc., but how
can computer information be 'locked'? By placing the data into a non
intelligible form, we effectively exclude everyone from access to the
intelligence contained within the information.
The DEA's main and primary data safeguard is the automatic deletion of the
original plaintext information. Encryption then provides the storage
security for the information while the information is en route, or is simply
being stored.
The integrity of data is not supplied by the DEA in any form. Instead, data
integrity is derived from reliable storage devices and media. It is the
primary concern of companies involved with the design and manufacture of
electronic data storage devices to be concerned with integrity of the data
stored on their devices. When you purchase a box of floppy disks, you may
notice that the manufacturer claims that the entire recording media has been
tested, that it undergoes many more rigorous test than those of the average
disk, and that it is guaranteed for the life of the disk. These are things
which you, or your firm look for when deciding who's product to buy. Who
needs unreliability anyway? Making intelligent choices like this for all
your computing needs will greatly enhance the integrity of the data in your
computing system environment, whether information is encrypted, or not.
It is also your responsibility to periodically inspect, test, and clean
your storage devices such as floppy drives for head alignment, read / write
accuracy, and read head cleaning. Hard disks should also undergo periodic
tests for reliability and defragmentation. These tips and suggestions will
go a long way toward data integrity and reliability with all the software
packages you use with your personal computer.
5.3 PRE-DEA FILE COMPRESSION
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
The DEA's Cipher Function output is a data entity known as the Stop Address.
The Stop Address must be represented as a 16-bit entity to preserve accuracy
and precision in the DEA system. As a result of this, the DEA will expand
the original file's size two (2) times. Thus if the plaintext file's size
is 1,000 bytes, then the DEA will output 2,000 bytes of ciphertext. There
are many other cryptographic algorithms with this annoying trait.
Certainly, this is an inconvenience, but unavoidable. The best method of
dealing with this, is to compress the desired file before submission to the
DEA with your favorite compression utility. The DEA does not provide
automatic input file compression, the user must perform this task manually,
or via an automated batch process.
Since the DEA operates upon one file at a time, you may find it more
convenient to gather up all files you wish to encode, compress them, then
submit the compressed archive to the DEA for encryption. This is an
organized approach to multiple file encryption since the DEA does not support
DOS wildcards.
Compression is very useful because it saves space when storing information,
and it saves time during the encryption process. When using pre-DEA
compression, you should be able to break-even, on average. That is, the
doubled DEA output file will usually be less than or equal to the original
uncompressed file. Text files will benefit the most from compression.
Note that during decryption, the DEA reads the 16-bit Stop Address, and
writes an 8-bit byte value to the output file. The extra storage space
occupied by the DEA file is released when the file is deciphered to its
original state.
5.4 COMPRESSION OF DEA CIPHERTEXT
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
The DEA ciphertext can be compressed, but this serves no really useful
purpose; it is briefly discussed here in the interest of completeness.
As the OTP setting becomes larger, the DEA Stop Address content will rise,
thus, both the low and high byte of the 16-bit data the DEA v.2.00 writes
as ciphertext contain 'information'. When the OTP setting is set between
1300 and 3000, there will be much fewer Stop Addresses in the ciphertext,
and therefore, only the low byte will carry significance; the 8-bit high
byte will be zero and carries no information, except bulk. DEA ciphertext
resulting from low OTP values are compressible by about 15-24 percent.
5.5 A SHORT LOOK AT THE DEA CIPHERTEXT
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Below, we look at the hexadecimal bytes resulting from the encipherment of
7 bytes of binary zero plaintext with the same key, but different OTP
settings:
OTP: 959 (Note: OTP was raised later to 1,300 minimum)
enciphered bytes: 89 00 C3 00 15 00 D5 00 26 00 56 00 32 00
OTP: 1571
enciphered bytes: CC 03 C7 00 CC 00 0B 04 04 00 22 00 E4 03
OTP: 5000
enciphered bytes: CC 03 B3 0B 13 0A 0B 04 CD 00 D9 06 E4 03
OTP: 10000
enciphered bytes: CC 03 B3 0B 13 0A 0B 04 AB 18 D9 06 E4 03
OTP: 20000
enciphered bytes: CC 03 B3 0B 13 0A 0B 04 AB 18 D9 06 E4 03
Observe that for this data sample, the OTP of 20,000 takes longer than the
OTP of 10,000 but produces no ciphertext changes. As the OTP setting
increases, the ciphertext will gradually take on a concrete form as shown
above. Thus, 03CC is a hexadecimal address, so is 0BB3, etc. Since the DEA
ciphertext assumes its most concrete form when it contains 100 percent Stop
Addresses, 100 percent Stop Address content is virtually guaranteed by a one-
time-pad value of 20,000 digits; there is nothing to be gained by extending
the OTP beyond 20,000 digits. Cryptographic security would be the same for
an OTP of 20,000 and one of 40,000 digits.
5.6 DEA v.2.00 ENCRYPTION TIMING TESTS
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Performed on 80286 PC AT Compatible
Operating at 12 MHz
Observe that the longer that the one-time-pad becomes, the greater the time
requirement, and the decrease in per second throughput. As the OTP value
increases, so does the DEA Stop Address content of the ciphertext and the
decrease of shuffled plaintext information bits. The advantage of higher
OTP settings is the thorough and unrelenting breakage of plaintext-to-
ciphertext relationships; this feature of the DEA comes at a price: time.
The faster your computing hardware, the larger the OTP settings you can
realistically select and use. However, the general timing and throughput
statistics given here will be valid for all PC processor types; larger OTP
values will slow down even the most powerful 80486, or Pentium(tm) processor.
File Size: 154 bytes
One-Time-Pad Size: 775 digits
Time: 13 seconds
Throughput per second: 11
File Size: 154 bytes
One-Time-Pad Size: 1000 digits
Time: 16 seconds
Throughput per second: 9.6
File Size: 154 bytes
One-Time-Pad Size: 2000 digits
Time: 30 seconds
Throughput per second: 5.1
File Size: 154 bytes
One-Time-Pad Size: 3000 digits
Time: 43 seconds
Throughput per second: 3.581
File Size: 154 bytes
One-Time-Pad Size: 4000 digits
Time: 56 seconds
Throughput per second: 2.75
File Size: 154 bytes
One-Time-Pad Size: 5000 digits
Time: 71 seconds
Throughput per second: 2.169
File Size: 154 bytes
One-Time-Pad Size: 6000 digits
Time: 84 seconds
Throughput per second: 1.833
File Size: 154 bytes
One-Time-Pad Size: 7000 digits
Time: 97 seconds
Throughput per second: 1.5876
File Size: 154 bytes
One-Time-Pad Size: 8000 digits
Time: 110 seconds
Throughput per second: 1.400
File Size: 154 bytes
One-Time-Pad Size: 9000 digits
Time: 123 seconds
Throughput per second: 1.2520
File Size: 154 bytes
One-Time-Pad Size: 10000 digits
Time: 137 seconds
Throughput per second: 1.12408
5.7 MULTIPLE ENCRYPTION AND PRACTICALITY
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Some Shareware data encryption software tools reviewed by Nellis du Maurier
Information Security are designed around the basis of multiple encryption
via different algorithms and / or double encryption. The basic philosophy
of cryptography is the design of an algorithm which is extremely secure in
one pass over the plaintext. Even the simplest of algorithms can achieve
a gain in strength via multiple encryption; it simply serves to double or
triple the keyspace. It does make things more difficult, but why do it
when the security of the algorithm must be judged from a single encryption?
How many times would one have to encrypt something with algorithm A so that
algorithm A's keyspace is equivalent with algorithm B, which requires only
one encryption?
Regardless of what your intuitive definition of cryptography may be, there
is no cryptographic algorithm which can be made absolutely, unequivocally
one hundred percent unbreakable. Cryptography can never provide an eternal
blockade to the original document, period. This applies to all crypto
systems, past, present, and future. Cryptography by design is, and must
be, a reversible "reaction" just like water can be turned to ice, and ice to
water.
Multiple encryption is seen by the crypto community as a weakness. If
several algorithms are chained together, then the effective keyspace becomes
larger, but would such a system still be practical? What of key management?
Multiple encryption with the DEA is not recommended as the file size will
double with every additional encryption. Sure, strength rises, but so does
the time and storage requirement.
In short, there is no advantage to multiple encryption with the DEA. If,
however, the DEA is used in a situation where a number of workers contribute
to a project, the supervisor may decide to implement a final supervisory
post-DEA encipherment as a precautionary step. This way, access to the data
requires two people: the supervisor, and some other person in charge of the
DEA key. This is analogous to a bank vault having the combination split
among two bank employees. This strategy can certainly be implemented; you
may desire to use the DES as post-DEA encipherment as it is fast and uses
a key no greater than seven (7) characters. Ciphertext will expand by zero
percent with the DES in this situation.
Chapter Six
═════════════════
6.1 PREVIOUS VERSIONS OF THE DATA ENCRYPTION ALGORITHM
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
The DEA was first released as a public evaluation on April 13, 1993. Several
weeks thereafter, version 1.50 was released. These programs have similar
internal workings but are all mutually exclusive as the result of Cipher
Function and other minor and major enhancements. Version 1.00 and 1.50 did
not expand the ciphertext as version 2.00 does now. They also did not
incorporate the DEA v.2.00 Cipher Function. These previous versions produced
their two one-time-pads externally to the DEA program. They do, however,
incorporate the same mod-mult-random-feed algorithm as DEA v.2.00. The DEA
Release v.2.00 is a transcribed work.
DEA keys from these previous versions should be discarded and not used with
the DEA v.2.00 even though the DEA key data structure has not physically
been changed.
6.2 COVERT AND PRACTICAL CRYPTANALYTIC TECHNIQUES
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
All users of the DEA and other cryptographic software / hardware tools should
be keenly aware that the term 'cryptanalysis' does not have to be interpreted
scientifically; it can be applied effectively via pragmatic methodology.
One tip to remember, before we examine the standard lot of covert and stealth
techniques, is your wordprocessor. Wordprocessors typically produce back
up files (.BAK), and or temporary timed as-you-work back up files which are
deleted after you finish using the wordprocessor. To maintain a high level
of information security, you are encouraged to delete the plaintext (.BAK)
equivalent of files you intend to encode with the DEA with the MFD program.
If you routinely encode documents with the DEA after you finish with your
wordprocessor, always ask yourself "Do I have any plain versions of this
file left in my system?" This is your cue so that you always check for the
possibility of plaintext file equivalents.
When you have a timed back up feature on your wordprocessor, the situation
is a little more complicated. If you have a back up file, you can delete
it via the MFD. However, timed back up data is usually directed into a
file which is erased by the wordprocessor when you exit the program. At
this moment in time, the timed back up file will probably contain a high
percentage of the actual data in the real document. The timed back up
file's data is not deleted from the disk; the entry in DOS's File Allocation
Table is deleted, marking the disk space as available -- the actual data
is still there! Since the MFD utility requires a file name to be supplied,
the MFD cannot be used when a wordprocessor automatically deletes a temporary
timed back up file. This is a problem which has no solution at the moment.
It is important that you realize this, as ignorance of this fact may prove
embarrassing. One possibility, however, is to load another file into the
wordprocessor, make some deliberate changes to it, forcing the wordprocessor
to create a new timed back up file, overwriting the older timed back up, then
exit the wordprocessor without saving the changes -- they were deliberate.
This is a workable solution, but take note that the old timed back up is
only overwritten once by the new timed back up file of same or larger size,
unlike the ten (10) times of the MFD. In such a hypothetical case, the data
from the original timed back up file, could possibly be salvaged via very
sophisticated data recovery hardware.
There are many practical methods of 'cryptanalysis', and you must be aware
that enciphering data is only a part of the overall information security
procedure. It is absolutely essential to have trustworthy and reliable
personnel and to follow strictly the procedures outlined by your firm's
information security officer(s) for each corporate department where the
principles of information security apply. Physical methods include burglary
(the infamous Watergate Hotel scandal), rummaging through corporate or
personal trash, stealing documents just before they are shredded etc.
Covert methods include bribery, blackmail, and staff infiltration. Below,
we look at two common stealth techniques.
Traffic analysis is used to infer some useful information which may be
pieced together later to build a case, for example. Here, it is of interest
where the messages originate from, where they are transmitted to, the size
of the messages, and the time of day the messages are sent. If the messages,
for example, originate in Columbia, and they are sent to Miami, then we can
infer at least something.
Tempest analysis is a true stealth technique which can be implemented from
within a well equipped van parked not far from the site. This involves the
remote detection of electromagnetic signal emissions from your computer.
Actually, they can see just about everything you type on your keyboard; this
method is focused upon the electromagnetic signal emissions of the keyboard.
With the design of the DEA, this method poses a very minimal threat to the
DEA user, as the DEA key is only referenced via its ID number; the key is
not physically typed out, and that's what this technique is geared up for.
Still, they may see your OTP settings, and your file names. If this
surveillance activity is suspected and you are creating new DEA keys, then
you should, perhaps, use the GENKEY utility somewhere else, possibly in an
environment where there are ten to twenty PC's close together; the
electromagnetic signal emissions from all of these (provided they are being
used), would be difficult to separate.
Another interesting stealth technique involves the placement of a
specifically designed computer virus which would intercept a key, encode it,
and place the data somewhere on your hard disk where the designer would
then extract it, decode it, and then have your very own key(s).
As encryption algorithms become more sophisticated, the number of different
covert strategies will also surely rise. There are many almost insignificant
gaps and user oversights which can provide the practical cryptanalyst with
just enough information to allow him to worm into your 'secure' system. The
best advice is to become fully acquainted with the encryption system you use
and then to analyze various scenarios known to pose potential security
breaches.
6.3 DATA ENCRYPTION AND THE LAW
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Up to a few years ago, the field of cryptography was mostly limited to
governments and special government departments such as national security,
and the secret service. Of course, the average citizen, hackers, and trained
experts have at one time or another undertaken to design and implement their
own algorithms. This has certainly provided the NSA with a wealth of ideas,
as cryptography is a science continually searching for diversity of
technique.
In 1991, the US proposed Senate Bill 266. This bill was mostly designed
as anti-crime legislation. Within the text of the proposed legislation,
there was a clause stating that all manufacturers of secure communications
equipment be so designed as to allow the government to recover the plain
text of whatever form the communication took when appropriately authorized
by law. Although this bill was defeated, the government has introduced
similar disturbing legislation which is designed to meet the same end
objectives.
Today, in 1993, the US government is proposing, just as it did in 1977 with
the DES, a new cryptographic device called Clipper. Clipper is a hardware
encryption device designed for telephonic equipment. It would seem that
governments are uneasy, perhaps rightly so, about real information
security tools, and the desire to standardize government encryption protocols
is an indication of this fear. On the positive side, however, Clipper is an
advance in telephone communications technology lending privacy and
confidentiality to millions of users, a useful addition which has long been
overdue. However, it is felt that the Clipper device will not survive in the
free market if such exotic telephones are to cost upwards of $700 dollars.
Indeed, it is far cheaper and more reliable to transmit private and
confidential information (encrypted) via a standard modem-fascimilie card,
which is now widely available. Despite the wide public mistrust of this new
government spearheaded technology, the Clipper initiative seems bound for
failure in terms of public acceptance. Perhaps most importantly, the Clipper
initiative is a gauge of public and organizational opinion on the subject of
information security in an 'ecosystem' of information dependence and
mastery.
As everyone's attention is turned to Clipper, we might pause and ask
ourselves "What has the government planned in the non-voice computer
encryption arena?" Are we headed for a police state? As you read the
accompanying INTERNET articles, you will probably realize that Clipper, even
if the tremendous odds are overcome, will not succeed in controlling crime
of any nature. It must, therefore, be assumed that Clipper is a prelude of
things to come - something bigger and far more widespread in terms of control
over information.
Here is a technical review of the unclassified data known about the Clipper
chip taken from the INTERNET sci.crypt conference on
April 21, 1993:
////////////////////////////////////////////////////////////////////////////
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
////////////////////////////////////////////////////////////////////////////
Article 15742 of sci.crypt:
Path: lynx.unm.edu!umn.edu!news-feed-1.peachnet.edu!bogus.sura.net!darwin.
sura.net!guvax.acc.georgetown.edu!denning
From: denning@guvax.acc.georgetown.edu
Newsgroups: sci.crypt
Subject: REVISED TECHNICAL SUMMARY OF CLIPPER CHIP
Message-ID: <1993Apr21.192615.3465@guvax.acc.georgetown.edu>
Date: 21 Apr 93 19:26:15 -0400
Distribution: world
Organization: Georgetown University
Lines: 167
Here is a revised version of my summary which corrects some errors
and provides some additional information and explanation.
THE CLIPPER CHIP: A TECHNICAL SUMMARY
Dorothy Denning
Revised, April 21, 1993
INTRODUCTION
On April 16, the President announced a new initiative that will bring
together the Federal Government and industry in a voluntary program
to provide secure communications while meeting the legitimate needs of
law enforcement. At the heart of the plan is a new tamper-proof encryption
chip called the "Clipper Chip" together with a split-key approach to
escrowing keys. Two escrow agencies are used, and the key parts from
both are needed to reconstruct a key.
CHIP CONTENTS
The Clipper Chip contains a classified single-key 64-bit block
encryption algorithm called "Skipjack." The algorithm uses 80 bit keys
(compared with 56 for the DES) and has 32 rounds of scrambling
(compared with 16 for the DES). It supports all 4 DES modes of
operation. The algorithm takes 32 clock ticks, and in Electronic
Codebook (ECB) mode runs at 12 Mbits per second.
Each chip includes the following components:
the Skipjack encryption algorithm
F, an 80-bit family key that is common to all chips
N, a 30-bit serial number (this length is subject to change)
U, an 80-bit secret key that unlocks all messages encrypted with the chip
The chips are programmed by Mykotronx, Inc., which calls them the
"MYK-78." The silicon is supplied by VLSI Technology Inc. They are
implemented in 1 micron technology and will initially sell for about
$30 each in quantities of 10,000 or more. The price should drop as the
technology is shrunk to .8 micron.
ENCRYPTING WITH THE CHIP
To see how the chip is used, imagine that it is embedded in the AT&T
telephone security device (as it will be). Suppose I call someone and
we both have such a device. After pushing a button to start a secure
conversation, my security device will negotiate an 80-bit session key K
with the device at the other end. This key negotiation takes place
without the Clipper Chip. In general, any method of key exchange can
be used such as the Diffie-Hellman public-key distribution method.
Once the session key K is established, the Clipper Chip is used to
encrypt the conversation or message stream M (digitized voice). The
telephone security device feeds K and M into the chip to produce two
values:
E[M; K], the encrypted message stream, and
E[E[K; U] + N; F], a law enforcement field ,
which are transmitted over the telephone line. The law enforcement
field thus contains the session key K encrypted under the unit key U
concatenated with the serial number N, all encrypted under the family
key F. The law enforcement field is decrypted by law enforcement after
an authorized wiretap has been installed.
The ciphertext E[M; K] is decrypted by the receiver's device using the
session key:
D[E[M; K]; K] = M .
CHIP PROGRAMMING AND ESCROW
All Clipper Chips are programmed inside a SCIF (Secure Compartmented
Information Facility), which is essentially a vault. The SCIF contains
a laptop computer and equipment to program the chips. About 300 chips
are programmed during a single session. The SCIF is located at
Mykotronx.
At the beginning of a session, a trusted agent from each of the two key
escrow agencies enters the vault. Agent 1 enters a secret, random
80-bit value S1 into the laptop and agent 2 enters a secret, random
80-bit value S2. These random values serve as seeds to generate unit
keys for a sequence of serial numbers. Thus, the unit keys are a
function of 160 secret, random bits, where each agent knows only 80.
To generate the unit key for a serial number N, the 30-bit value N is
first padded with a fixed 34-bit block to produce a 64-bit block N1.
S1 and S2 are then used as keys to triple-encrypt N1, producing a
64-bit block R1:
R1 = E[D[E[N1; S1]; S2]; S1] .
Similarly, N is padded with two other 34-bit blocks to produce N2 and
N3, and two additional 64-bit blocks R2 and R3 are computed:
R2 = E[D[E[N2; S1]; S2]; S1]
R3 = E[D[E[N3; S1]; S2]; S1] .
R1, R2, and R3 are then concatenated together, giving 192 bits. The
first 80 bits are assigned to U1 and the second 80 bits to U2. The
rest are discarded. The unit key U is the XOR of U1 and U2. U1 and U2
are the key parts that are separately escrowed with the two escrow
agencies.
As a sequence of values for U1, U2, and U are generated, they are
written onto three separate floppy disks. The first disk contains a
file for each serial number that contains the corresponding key part
U1. The second disk is similar but contains the U2 values. The third
disk contains the unit keys U. Agent 1 takes the first disk and agent
2 takes the second disk. Thus each agent walks away knowing
an 80-bit seed and the 80-bit key parts. However, the agent does not
know the other 80 bits used to generate the keys or the other 80-bit
key parts.
The third disk is used to program the chips. After the chips are
programmed, all information is discarded from the vault and the agents
leave. The laptop may be destroyed for additional assurance that no
information is left behind.
The protocol may be changed slightly so that four people are in the
room instead of two. The first two would provide the seeds S1 and S2,
and the second two (the escrow agents) would take the disks back to
the escrow agencies.
The escrow agencies have as yet to be determined, but they will not
be the NSA, CIA, FBI, or any other law enforcement agency. One or
both may be independent from the government.
LAW ENFORCEMENT USE
When law enforcement has been authorized to tap an encrypted line, they
will first take the warrant to the service provider in order to get
access to the communications line. Let us assume that the tap is in
place and that they have determined that the line is encrypted with the
Clipper Chip. The law enforcement field is first decrypted with the
family key F, giving E[K; U] + N. Documentation certifying that a tap
has been authorized for the party associated with serial number N is
then sent (e.g., via secure FAX) to each of the key escrow agents, who
return (e.g., also via secure FAX) U1 and U2. U1 and U2 are XORed
together to produce the unit key U, and E[K; U] is decrypted to get the
session key K. Finally the message stream is decrypted. All this will
be accomplished through a special black box decoder.
CAPSTONE: THE NEXT GENERATION
A successor to the Clipper Chip, called "Capstone" by the government
and "MYK-80" by Mykotronx, has already been developed. It will include
the Skipjack algorithm, the Digital Signature Standard (DSS), the
Secure Hash Algorithm (SHA), a method of key exchange, a fast
exponentiator, and a randomizer. A prototoype will be available for
testing on April 22, and the chips are expected to be ready for
delivery in June or July.
ACKNOWLEDGMENT AND DISTRIBUTION NOTICE. This article is based on
information provided by NSA, NIST, FBI, and Mykotronx. Permission to
distribute this document is granted.
////////////////////////////////////////////////////////////////////////////
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
////////////////////////////////////////////////////////////////////////////
The social impact of the clipper chip warrants close attention and may even
result in the outlawing of all other forms of data encryption, and give the
US a North American monopoly over all corporate and private information.
These fears are real and you are encouraged to think about it now. For
example, private data encryption in Spain is illegal. There are also other
countries on the globe which prohibit private sector encryption. Still, it
is very interesting to observe the US's initiative and proposed
implementation of this new technology.
There are several main reasons why governments are uneasy about real data
encryption tools: they expend considerable resources in the attempt to
recover the original plain text, often failing. They desire to control
subversives, terrorists, spies, drug lords, and plain criminals. Of course,
this is laudable; we all want to be as safe and secure as possible. Anyone
who offers real information security tools, would be just as guilty as those
who perpetrate the crime. The only sure method of combatting destructive
forces is the complete outlawing of all data encryption, or the
standardization of encryption technology on as wide a scale as possible.
The legal issues raised by information security and law enforcement are
formidable. If laws are invoked to make all non-government approved
encryption algorithms illegal, then nobody except the government itself will
have true privacy. This scenario is a very real possibility in the near
future! Where do we draw the line between security and control of crime?
Can crime be effectively combatted by other means? How much of a hindrance
does top-of-the-line information security pose to the pursuit of law
enforcement and the weeding out of subversives and undesirables? Can
rigorous control over electronic information really reduce crime and other
negative social ills by 50 to 75 percent? By ten percent? By five percent?
Has the outlawing of information encryption in Spain resulted in a better
country to live in? Thus, if the government intends to implement some or all
of the threatened possibilities hanging over information security like a
dark and ominous cloud, it must provide conclusive proof to these and other
questions. If such proof is not forthcoming, then we can all continue to
enjoy our freedom and just privacy.
Nellis du Maurier Information Security wishes to provide the best
information security possible, but does not desire to obstruct the law. If
the DEA v.2.00 does become involved in a criminal case, it is the
responsibility of the accused to provide law enforcement authorities with the
key data; Nellis du Maurier has no method whatsoever of determining the key;
there are no shortcuts, trapdoors, analytic methods, nor duplicate keys in
the DEA v.2.00 system; only brute-force attacks will succeed, and these will
require more time than can be humanly tolerated.
In the next few years, you will probably hear much more about information,
privacy, and data encryption. Unlike the other major infrastructures we
currently have such as bridges, highways, telephones, etc., the electronic
information networks and the resultant electronic information infrastructure
has only begun around 1986, it is only about seven (7) years in the making.
As more and more information is routed and stored electronically, the issues
of privacy, confidentiality, and of necessity, encryption will come to the
fore.
If you are concerned or just interested in cryptography, new trends, new
products, the politics of data encryption, you may want to check into the
INTERNET. One conference is mostly technically devoted, the other is mostly
devoted to the political ramifications of this information technology on
society presently, and in the near future.
6.4 THE DEA ADVANCED COMMERCIAL VERSION - DEA ACV v.2.00
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
The DEA Release v.2.00 operates with a key length of one hundred and eighty
(180) bytes, or 1,440 bits. This is far more than the DES (56 bits),
IDEA(tm) (128 bits), and all other private sector cryptographic tools
currently available and in use. This probably also includes the new clipper
hardware chip for telephonic equipment.
Breaking the DEA entails the process of trying all 1,440 bit permutations
applied to, say, the first 160 bytes of DEA ciphertext to determine if
intelligible plain text resulted. This does not take into account the OTP
setting which is also key information. The OTP value forces the brute-force
attacker to try all (modestly) 10,000 OTP variations for each 1,440 bit key.
Thus, breaking even the DEA v.2.00 is not at all likely via brute force
means. It can be done in theory, and in practice given enough time, but by
that time, the attacker will probably be in the ground and will have lost
interest. The brute-force strategy is the only method of breaking the DEA,
as the DEA can and will sever completely all relationships between plaintext
and ciphertext.
The question now is: "What can be done so that the DEA ciphertext will
resist attack, even if the correct key and OTP
data is applied?"
If the DEA ciphertext could be purposely 'corrupted' by some means, then
even if the correct key data were applied, original plain text information
recovery would not succeed, period. The purposeful 'corruption' serves to
place the DEA ciphertext into a 'security envelope'. Now, both the original
plaintext is in a secure 'envelope' (DEA ciphertext), and the true identity
of the ciphertext itself is protected. A simple idea would be to encipher
the DEA ciphertext, resulting in the user having two keys, on for the DEA and
another for the post DEA encipherment. However, if the attacker knew that
the user was using DES as post DEA encipherment, then the attacker must go
through all DES keys, all DEA keys, plus all DEA OTP settings. This is
an extremely arduous task and would require thousands of Cray super computers.
But, as unappetizing a task as it is, even this can, in theory, be reversed.
This simple idea does not expand the DEA ciphertext itself, and succeeds in
raising the work factor enormously.
Whatever means are used to cloak the end result of any ciphertext, one fact
holds true: the work factor is increased and the possibility of reversing
the many 'envelopes' remains constant at greater than zero. If we make the
effective keyspace larger, we make the brute-force strategy a more torturous
affair, and we buy ourselves more private time.
While the answer to the above question has not been decisevly settled, the
best median seems to be the adoption of a two hundred (200) byte random user
defined key. Thus, the DEA ACV v.2.00 will use the standard DEA
key structure plus an additional 200 byte key to protect the DEA ciphertext
itself. This will effectively raise the DEA keyspace to 2^2,304,000 or
256^36,000. Further, the ACV will define the usage of the Start Vector, a
value between zero and nine. The Start Vector is defined in DEA v.2.00 as
zero. It should be noted that only the first few Stop Addresses of the
DEA ciphertext are susceptible to brute-force attack; the 200 byte user key
is designed to cloak the true identity of these Stop Addresses. The user
defined 200 byte key will physically reside within the DEA.KEY file, but
the DEA ACV key file will not be compatible with DEA v.2.00. Registered
users can select the length of the user defined key from 200 to 2000 bytes.
This program's application of this key does not require much time at all; it
is not a full file encryption, it is only designed to protect the first few
x-number of DEA cipher bytes from vulnerabilities of a brute-force attack.
Note that the application of the DEA ACV 2.00 key and OTP will not recover
the plaintext; the user defined key must be used first, this is just what we
want.
The DEA ACV v.2.00 will become available in January 1994, pending demand.
6.5 DEA PROBLEM REPORTS
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
The DEA Release v.2.00 was designed to be operated under the MS-DOS(tm)
operating system by standard IBM(tm) and compatible hardware. Any problems
reported with DOS 5, or 6 will receive prompt attention.
The DEA may or may not operate as documented with other operating systems.
In these situations, problems would most likely be associated with command
line switches, and redirection pipes.
If you have a troublesome problem, you are asked to complete the DEA
PROBLEM REPORT. There is a file in the DEA package called PROBLEM.RPT for
this purpose. Please specify your operating system, and the difficulties
you encountered, along with the particulars of the situation. Please make a
note of any line number indicated by the particular program.
Nellis du Maurier will investigate all problem reports, but will not
guarantee a successful resolution for all cases.
Chapter Seven
═════════════════
7.1 PRELUDE TO THE DEA SECURITY ANALYSIS
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
During the development of the DEA, Nellis du Maurier evaluated many of the
available shareware data encryption products offered by various merchants.
Most provide adequate protection from moderate threats. Some used
compression, most simply adopted the 16-year old DES 'standard', and some
went their own way and implemented their own proprietary algorithms. One
product stated that 'Level 2' encryption was based on the DES algorithm, but
used only one (1) of the sixteen (16) rounds of encipherment. No mention
was made as to just which DES mode is being used. Electronic codebook?
Cipher block feedback? Cipher block chaining? One product, of respectable
calibre, used no less than five (5) pseudorandom number generators, PRNG's.
However, all except one program, used the standard secret password approach
to data encipherment. That one exception was an implementation of the
Israeli Mossad technique. Indeed, the many methods in the science of
cryptography is 'limited only by the imagination'. One product, was a true
implementation of the RSA system, but because of the RSA mathematics, it
could not use long RSA keys.
It would seem, then, that although cryptography as a science implicitly
demands creativity, there has been very little creative progress judging
from the available wares. The data security products offered by numerous
merchants, and the technology embodied within them, is very old news to the
National Security Agency (NSA), and other government agencies. The real
problem with these products is that most are outdated, and are trivial
programs. But, even a very simple cipher can deter an individual from
making an attempt to read your private mail or documents. The available
products, up to now, seem to have only envisioned moderate security; and this
is fine for most private sector uses of cryptography.
How can an individual judge the quality, security, and strength of an
information security tool? If you have no experience with cryptography,
then you cannot make such evaluations. How do you go about evaluating a
product which employs technology never before heard of, like the DEA? The
ciphertext of one algorithm looks just as random as the next. Not simple
at all. There is no getting around the fact that you must have some
experience, and an understanding of a number of cryptographic principles and
techniques. An information security consultant can certainly help in
evaluating a product, and giving you valuable feedback.
However, there are several aspects which even an inexperienced person may
use to determine the strength of an algorithm as follows:
1. does the algorithm break all statistical, structural, and linguistic
correlations between the plaintext and ciphertext?
2. does an analysis of the ciphertext allow for the recovery of the key,
or plaintext?
3. can the traditional plaintext-ciphertext analysis be used to advantage?
4. can the ciphertext be in any way used to attack the algorithm's weak
spots?
5. How many different methods are available for attacking either the
ciphertext, or the key? (the fewer, the better)
6. how large is the keyspace?
Even if the algorithm holds up against the
above four (4), if there are only 10,000
keys, even a PC XT can go through all of
them in less than 24 hours.
In general, good cryptographic algorithms are designed so that ciphertext
cannot be used against the algorithm itself. If this one paramount
principle is strictly adhered to, the attacker is given no other choice, and
he must then employ a brute-force key attack. A brute-force key, or keys
attack will always succeed, in both theory and practice. This fact hangs
like an anchor about the neck of the science of cryptography. If it can
be "done", it can also be "undone". So then, even if the attacker must
undertake a brute-force methodology, what provides the "security" of the
system?
The four factors listed above are typical shortcut strategies which are used
in the science of cryptanalysis. Most cryptographic algorithms leave faint
tell-tale signs of their inner algorithmic procedures within the ciphertext,
and these minute patterns carry-over into the ciphertext where the science
of cryptanalysis fully exploits their existence. Now, if the ciphertext
itself cannot be exploited, then the attacker must go through a key attack.
In modern cryptosystems, it is only the key which provides the security. All
modern systems use a fairly long key. The best example here, is the true
one-time-pad, where the key is as long as the message itself. It is the
trial-and-error process of trying all keys which is so painstaking and time
consuming. Attacking even the DES by 'hand' would be impossible. But, with
modern computers, brute-forcing an algorithm is much easier, and the time
required for this procedure depends solely upon the speed of the computer.
Consider this: there are 256^7 keys in the DES algorithm, suppose that a
supercomputer could calculate and verify all 256^7 keys in one (1) hour.
This now means that your message / document can be deciphered in only one
hour. Where is the security now? Security and time are synonymous terms in
cryptography. Thus, we can say without reservation, that as computer speed
increases, the security provided by all cryptographic algorithms will
decrease by the same factor. It is the time required to try one key which
actually defines the security of the algorithm, in the measuring unit of
time, provided there are no analytic shortcuts. The large number of keys in
a system is what provides the 'timed' security.
7.2 THE DEA v.2.00 SECURITY ANALYSIS
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
While is possible to create many different cryptographic algorithms of
various strengths with different design criteria, the basic fact of all
cryptosystems is that because they are reversible 'reactions', they are
therefore all open to attack, as it is precisely this fact of reversibility
that introduces the inherent weakness into all systems. The attack upon any
algorithm must be based upon a thorough understanding of the algorithm in
question. This is the reason why military cipher algorithms are kept secret.
If you can not make reasonable working assumptions about the algorithm in
question, then you are effectively shut out from building any empirical data.
The attacker must, in this case, use all his cryptographic knowledge to
slowly gather working assumptions about the unknown cipher used.
The DEA uses two internal one-time-pads which contain only the digits zero
through nine. These digits can be thought of as a permutation of x-number
of digits, the actual total permutations possible in these one-time-pads
is defined thus:
P = 10^otp_size
where otp size is the size (in digits) of the one-time-pad
Thus, a one-time-pad size of 6,500 digits gives:
P = 10^6,500
The DEA's maximum 'permutation space' is therefore: 10^20,000, given the
maximum OTP setting.
If the one-time-pad size is say, 3 digits long, we then have 10^3 possible
permutations of 3 digits. We can represent these possible permutations as
ranging from 000 to 999. If our OTP was set to 6 digits only, then we have
10^6 possible permutations ranging from 000000 through to 999999. We may
think of 000000 as the 'first' permutation of 6 digits, and 999999 as the
'last', or 'highest' permutation of 6 digits. This is just like the
combination locks on some briefcases.
SELECT DIGIT FRAME SUMMATIONS AND THE SIZE OF THE STOP ADDRESS
--------------------------------------------------------------
The DEA is able to satisfy the DEA Cipher Function in the majority of cases.
'Cases' here is used to signify the input data set consisting of:
8-bit plaintext byte
one-time-pad permutation 'P'
select digit
stop address byte value
We must understand that there are two (2) random processes at work in the
DEA. The first is the random one-time-pad, the second is the random
multi-XORing of the DEA Cipher Function.
Different one-time-pads will have a different select digit "frame summation".
The frame summation will explain why a different OTP will produce a different
16-bit address given the same input data set.
To examine why the majority of addresses are less than 5,000, we need to
examine the frame summation and the XORing together. A different frame
summation will lead to a different XOR sequence. As observed, the XOR
sequence is relatively short for the majority of data input sets. What does
this short XOR sequence indicate about the XORing and the frame summation?
Obviously, the random numbers extracted from the frame led to an XOR sequence
in which the plaintext byte was transformed into the stop address byte value
in short order. Most of the frame summations are values less than 100.
The reason why the majority of addresses are less than 5,000 is because
the frame summations are significantly different from each other so that the
XORing "moves" the byte value along. In high DEA addresses, the XORing does
not "move" significantly in any direction for a while, thus XORing 50 with 17,
then 13, then 27, then 22... does not "move" the byte value very much, as
with frame summations of greater distance variety. Therefore the reason for
the DEA Stop Address size is the direct result of the 'distance' between the
successive select digit 'frame summations'. The larger these distances, the
more the XORing 'moves' the byte in either direction faster. In general, the
larger distances produce smaller Stop Addresses, while smaller distances cause
the Stop Addresses to enlarge. So, yes, the one-time-pad is responsible for
this phenomenon.
Can any statistical inferences be drawn from the DEA Stop Address sizes?
While inferences and hypothesis can certainly be drawn, they will not
aid in the process of analytic attacks. Larger OTP values will cause
the DEA Cipher Function to be satisfied in the majority of cases.
Such statistical methods give a clue as to the nature of the SD frame
summation values, but lead to a dead end when attempting to link Stop
Address size to either plaintext, or key information.
HOW DOES THE ATTACKER PROCEED FROM STOP ADDRESS TO PLAINTEXT?
-------------------------------------------------------------
There is no direct link between a DEA Stop Address and the original 8-bit
plaintext value of any kind. The 8-bit plaintext byte value does, however,
act as a 'control variable'. In other words, XORing begins from this
value, and ends with the SABV value. The 8-bit input byte represents only
25% of the total DEA Cipher Function's data input set. There is no method
of reversing this if the Cipher Function's data input set is not
conclusively known beforehand. If such an attempt is made without
certainty, it will result in the DEA Multiple Solution problem wherein
many different data input sets will result in the same Stop Address, and
there is no method available to prove the correctness of a DEA Cipher
Function data input set by this trial-and-error approach.
SO HOW COULD THE CRYPTANALYST ASCERTAIN THE CORRECT VALUES FOR THE SELECT
DIGIT AND STOP ADDRESS BYTE VALUE?
-------------------------------------------------------------------------
These control variables only control the DEA Cipher Function's multiple
XORing, and although they are responsible for the resulting Stop Address,
there is no way of going backward. They are not combined with the Stop
Address in any manner.
WHAT CAN BE SAID ABOUT TRADITIONAL PLAINTEXT-CIPHERTEXT ATTACK STRATEGIES?
--------------------------------------------------------------------------
As illustrated, the DEA cryptogram bears no structural, statistical, or
language specific correlations with the plaintext; it is completely devoid of
all plaintext correlations. The DEA has effectively severed any and all
traditional plaintext-ciphertext relationships. The availability of partial
plaintext and DEA ciphertext will compromise neither the remaining ciphertext,
nor the DEA key.
IS THERE THE POSSIBILITY OF THE CRYPTANALYST DETERMINING ANY CORRECT
INFORMATION WITH REGARD TO THE CRITICAL UNKNOWN CONTROLLING VARIABLES
OTP, SD, SABV, AND PLAINTEXT?
---------------------------------------------------------------------
The answer here is no. The basic reason for this is the DEA's multiple
solution problem. If there was but one solution for any of the data input
set variables, it would then be possible to ascertain for certain the actual
values, but with multiple solutions, none of the control variables may be
determined with accuracy and precision. All control variables, with the
possible exception of repetitive plaintext, oscillates on a byte-to-byte
basis.
EXPLAIN WHY THE DEA IS COMPLETELY DEVOID OF ALL PLAINTEXT - CIPHERTEXT
RELATIONSHIPS.
----------------------------------------------------------------------
The 'ciphertext' of the DEA is an EVENT, not a series of eight (8)
scrambled bits. The DEA records WHERE in the one-time-pad the DEA Cipher
Function's data input set was satisfied. The ciphertext is actually an
address, but may be considered as a 'timed event'. Since the DEA
incorporates two (2) random processes, the DEA Cipher Function is able
to completely sever all plaintext to ciphertext relations.
BRUTE-FORCE ATTACKS BASED ON KEY PERMUTATIONS
---------------------------------------------
The only avenue open to a potential attacker of DEA enciphered data is
via brute-force, that is, trying all possible 1,440 key bit permutations.
There is no shortcut method available in the DEA system. Brute-force
attacks will succeed with the DEA, just as surely with all other systems.
Since the DEA also treats the OTP value as key information, the brute-force
attack is not as clear-cut as it might be with other systems; the OTP value
increases the work factor substantially.
EXPLAIN 'RUNNING INTERNAL KEYS'
-------------------------------
The DEA creates a key for every input byte the DEA must process. Most
importantly, the DEA creates a one-time-pad for every plain byte. The
original user key provides the control over the Cascade Synchronization
produced by the system when it creates new one-time-pads. The Cascade
Synchronization is determined by the user key, and the plaintext data. The
plaintext data provides the control mechanism for the creation of new
one-time-pads as it affects the original fractions defined by the user
key data. Thus, a running DEA key is one which has its fractions modified
by DEA frame summation values. The SD, and SABV values are not affected;
they remain constant throughout the DEA process. The term 'running
internal key' is to be understood as a concept, not an exact entity.
While a running DEA key also contains 1,440 bits of key data, such a
hypothetical key cannot be applied to DEA ciphertext as this key has no
way of going 'forward', that is, it cannot maintain the original Cascade
Synchronization. The one-time-pad which serves as a random feed,
provides further security, as an OTP of length (x) is applied to each and
every running key. Therefore, the DEA running key, is protected by a
10^10,000 byte permutation, if the user selected an OTP of 10,000 digits.
ENTROPY AND THE DEA V.2.00
--------------------------
In the cryptographic past, the principle of entropy, or the measure of
physical disorder of a system, was a principle of integral importance in the
science of cryptography. This principle is usually applied to the ciphertext
output of an algorithm for analytic reasons. We know that all cipher
algorithms alter the original intelligible patterns of entropy into a new
'language' of differing entropy designed to be unintelligible. We also
know that the algorithm (a systematic procedure for something) will leave
some faint tell-tail residues in its output. When the entropy of the
ciphertext is uniformly distributed, then it is much more difficult for the
cryptanalyst to obtain a statistical 'grip' on the entropic environment he
needs to analyze. If we were to subject this paragraph to various
language analysis, we could compile a number of useful statistics. However,
where the data bytes are uniformly distributed over the entire alphabetic
spectrum (our English alphabet, ASCII, EBCDIC, etc.), we can make very few
statistical statements, except that all byte values are equally likely to
appear with relatively equal frequency.
The principle of entropy can be applied to all cipher algorithms which employ
substitution, transposition, or both. Entropy cannot be applied to systems
which are based upon mathematical operations such as the RSA, or the
Knapsack. That is to say, the principle of entropy cannot be applied blindly
and universally to all cryptographic algorithms.
The principle of entropy is fundamental to all of cryptography, as each
algorithm manipulates the original natural language entropy into a new
entropic language. But, it is interesting to note that not all algorithms
produce the new entropy via the same methods. Some algorithms rely heavily
upon some random function, or set of random functions as the source and
supply of their entropy. There are also algorithms which do not rely on an
internal supply of entropy with which to combine the plaintext. Instead,
these algorithms directly combine the plaintext with some type of reversible,
or invertable mathematical function, such as in the RSA design. Despite the
two divergent methods which can be employed, the desired net effect of
transforming the original entropy into a new unintelligible entropy is
achieved in both systems. In effect then, encryption is an algorithm
dependent translation process.
The principle of entropy in the DEA system is provided by the enormous
permutation space available from the one-time-pads. An OTP setting of 7,000
will provide 10^7,000 total 7,000 digit one-time-pads from which to draw
select digit frame summation values. This is the source of the entropy in
the DEA. While the DEA does combine the SD frame summation values with the
plaintext byte a random number of times, the final output is not a scrambled
8-bit byte, but rather, it is an address indicating where in the one-time-pad
the DEA Cipher Function's data input set was satisfied.
The DEA ciphertext does not display uniform probability space. With an OTP
of 20,000 digits, most DEA Stop Addresses will be less than 9,000. Is this
a weakness? What might it indicate about the C.F. data input set?
The size issue of the Stop Address has been addressed previously. It does
not matter whether the plaintext byte is in the low ASCII end or the high
end; large Stop Addresses may result from any ASCII byte value or any C.F.
data input set. The non-uniform Stop Address distribution is actually a
strength, rather than a weakness. It is a strength because of the DEA's
Multiple Solution Problem wherein completely different ASCII byte values can
map to the same or relatively same Stop Address. It is interesting to note
that this non-uniformity can not be exploited to advantage. With other
traditional systems this fact could and would be immediately exploited. The
ASCII 8-bit input byte and the resultant Stop Address display no direct
correspondence or relationships. We can never say that this byte value maps
to this Stop Address. The mapping is random and cannot be computed in
advance. If all C.F. data input set control variables are held constant, but
not the one-time-pad, then there is still just as much Stop Address variety.
If the one-time-pad along with the other C.F. data input control variables
were to be all held constant, then the same Stop Address would result every
time. Therefore, it is the one-time-pad which is directly responsible for
the Stop Addresses.
It is interesting to observe that while there is great permutation entropy in
the one-time-pads from byte to byte, there is a lesser degree of entropy in
the resulting Stop Address distribution. However as we have noted, this
non-uniform distribution cannot be cryptanalytically exploited, just as
entropy analysis cannot be applied to pure RSA ciphertext. If the ciphertext
of a particular algorithm is not a product of substitution, transposition, or
both, or some other invertable function, then analysis based upon entropy
will fail to yield any conclusive results. The application of entropy to
the RSA, for example, is cryptanalytically ridiculous. It is also futile to
apply this principle profitably to the DEA Stop Addresses in the hope of
getting a statistical 'hook' into the system.
WHAT CAN BE SAID ABOUT THE STOP ADDRESS SIZE AND THE NUMBER OF XOR'S?
---------------------------------------------------------------------
Suppose we have the Stop Address N and we wish to know how many times the
XOR operation was used, that is, starting with the plaintext byte P and
ending with the SABV, how many XOR's were performed? It is known that given
a Stop Address, the number of XOR's lies in the range
(N - 90%) to (N - 93.9%), which is roughly 6.1% to 10% of the Stop Address.
The uncertainty variance factor is 3.90% of the Stop Address.
Now, let us examine if we can make any reasonable working assumptions with
regard to this fact. Suppose we have a Stop Address of 4904 and the number
of XOR's was known to be 404 (actual case). We also know that the plaintext
byte P was transformed into the SABV via the agency of 404 XOR steps, that
is, 404 random numbers were scooped off the one-time-pad and XOR'ed with P to
result in the SABV value and the resultant Stop Address is 4904 at this
point. Can this information be applied to the attack of any DEA Stop
Address? The short answer here is that while this method of attacking
the DEA would seem to hold the greatest promise, it leads to complete
frustration. It is not possible to prove the values P and SABV beyond
doubt given the existence of Multiple Solutions. The only method of
proving P and SABV is to to also have knowledge of the actual
one-time-pad for this data input set. The one-time-pad cannot be
reconstructed via knowledge of the Stop Address, or the assumptions we
have made here. All the DEA's C.F. input data must be known beforehand
to prove with absolute certainty that this is how P was transformed into
the SABV, and thus, the Stop Address; the DEA is unique in that it
leaves absolutely no room for hypotheses and conjectures - either the
Cipher Function's data input set is known, or it is not, there is no
manner in which this fact can be circumvented.
As a side note, larger OTP settings increase security via increasing the
uncertainty as to the OTP's exact construction.
WHAT IS THE RELATIONSHIP BETWEEN SUCCESSIVE ONE-TIME-PADS?
----------------------------------------------------------
As with pseudorandom number generators and decimal periods from, for
example, 171 / 22307, there is a relationship between successive random
numbers, and also between successive digits of the decimal expansion.
We can define the explicit relationships via the agency of a formula.
The DEA's one-time-pads correspond to a function of many (thousands) of
independent sub-functions. With simple PRNG's, knowledge of only one
random number will allow all others of the sequence to be produced.
This is not the case with the DEA's one-time-pads. While there is some
degree of interdependence, the random feed to the mod-mult algorithm
effectively prohibits the drawing of such conclusions; it is the n-digit
long random feed, together with other variables which control the
relationship(s) between successive one-time-pads.
No statement is being made here to the effect that there is no
relationship(s), rather, the relationships are controlled by other
factors which are possessed of extremely large degrees of variability.
The actual relationships are controlled by all aspects of the DEA
Cipher Function data input set, including the plaintext.
EXPLAIN WHY THE DEA ONE-TIME-PAD IS UNIQUE
------------------------------------------
The DEA's one-time-pad is just like the decimal expansion of a rational
fraction. However, unlike a plain decimal expansion where ALL quotients
correspond to a single modulus, the DEA's decimal expansion is an unnatural
one in that it employs as many moduli as are necessary to produce the
required decimal length. Such an unnatural decimal period will never
correspond exactly with a decimal period derived from a 'natural' or single
modulus.
Many statistical properties of natural decimal periods especially the
reflexive cycle property is completely eliminated when multiple moduli are
employed in this fashion. While there are other statistical considerations,
their ranges and paramaters are fairly consistent, as they should be.
It is from this decimal period that the Select Digit Frame Summation (SDFS)
values are derived, which is the DEA's source of entropy.
WHAT TYPE OF CIPHER IS THE DEA?
-------------------------------
The DEA is a conventional cryptosystem, as opposed to a public key
system. It is a stream cipher operating upon one (1) eight bit byte at
a time. The DEA is not a block cipher such as Lucifer, and its
butchered cousin, the DES. Further, the DEA does not combine the key
with the plaintext, as is almost universally the case. Also, each eight
bit byte is processed as a single and separate entity; it bears no
relation to a past or next byte. The DEA is a symmetrical system,
meaning the same key applies to both encoding and decoding.
CONCLUSIONS OF THE SECURITY ANALYSIS
------------------------------------
We conclude that the DEA v.2.00 is computationally secure but not
unconditionally secure. We further conclude the DEA ciphertext is not
vulnerable to attack by traditional cryptanalytic techniques, or by
methods specifically tailored to the DEA itself. We conclude the DEA
may be broken only by brute-force key trials. Since the DEA's keyspace
is 256^180, or 2^1440, it will require far more time for a brute-force
attack to succeed with the DEA as contrasted to the best public
algorithm(s) including the 80-bit Clipper voice encryption chip.
It is surmised that the DEA with just a 180 byte key is less secure than
the RSA algorithm with a 500-digit prime key number. This results from
the fact that one key is 180 bytes while the other is 500 bytes; this
difference should be obvious. The DEA ACV addresses this issue with the
200 byte random user-defined key. Also to be considered in this
comparison, is the different methods employed for brute-forcing each
algorithm, if indeed the RSA has been used in its 'native' non-hybrid
mode. In general, all other things being equal, the longer the key, the
more time consuming and laborious the brute-force attack will be.
However, as the RSA is employed mostly as a hybrid system wherein the
bulk of the actual document / message is processed by a more
time-respecting algorithm such as DES, IDEA(tm), or some other, it can
be said that the DEA is superior to the RSA in THESE HYBRID CASES ONLY.
This assessment is based on the known key length of the RSA-secondary
algorithm.
POINTS TO REMEMBER
------------------
Contrary to what others may believe to be the case, cryptography can
NEVER provide absolute unequivocal guarantees of security if we
understand that the term is used in a reversible sense. The more
'secure' the system, the more it will border on irreversability, and as
we know and understand, encryption must be reversible to be useful, as
it is information we wish to MAINTAIN but NOT SHARE for a period of
time. For example, the Beale Cipher is a unique cipher, but with the
loss of the key document, it becomes non-reversible, and thus, it loses
its usefulness. The task of combining the pragmatic element with the
element of security is not at all easy. And, it is indeed these two
functionally opposed needs which control the science of cryptography.
Given these unmovable theoretic facts, it is comforting to know that
cryptography does work, is used, and will be used and relied upon even
more in the near future. Apart from physical methods, cryptography is
the only solution to the information problem MAINTAIN but NOT SHARE.
Chapter Eight
═════════════════
8.1 REGISTRATION AND ORDER FORM
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
The registration fee to continue using the DEA beyond the 30 day trial
evaluation period is twenty (20) US dollars, or thirty (30) dollars
Canadian funds. Overseas orders are accepted in the form of international
money order. Please note that there are no fees beyond the registration
fee; it is considered "payment in full". Please print the file
REGISTER.USR, fill it out as indicated along with your check or money
order.
Registration entitles you to program updates at significant savings. You
will also be advised of DEA security analysis issues. The DEA ACV
2.00 is also available to you, once you become a registered user.
Negotiated corporate site licenses are available. Please write the firm
at the address below:
Nellis du Maurier Information Security
33 Isabella St., Ste. 1005
Toronto, Ontario M4Y 2P7
Canada
8.2 DEA USER FEEDBACK
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
The software you are using is a genuine Nellis du Maurier product. Nellis
du Maurier is pleased to hear from its end users regarding their
information security needs and these products. If you require additional
features, and / or products, please contact the above in writing.
Pleae note that special features are considered 'custom programming
projects', and prices will vary according to the nature of the
requested features.
Updates for the Shareware version are scheduled for regular intervals
and will incorporate the most requested features. Thus, user
feedback is strongly encouraged.
8.3 THE DEA v.2.00 OPERATING SPECIFICATIONS
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Although a seasoned professional will be able to make sense of the internal
operating characteristics of the DEA v.2.00 algorithm, these specifications
and the entire design of the algorithm are the property of Nellis du
Maurier Information Security. The company desires to encourage
discussion, inspection, and analysis of the DEA design, but at the
same time desires to maintain control over its commercial rights to
the algorithm. At the time of this electronic printing, the DEA is
protected by the copyright laws of Canada. It is also protected by
Canadian intellectual property laws. A patent application for the DEA
is scheduled for early 1994. While discussing the issue of algorithm
availability and commercial protection, it is stated here that the
DEA.EXE file contains an encoded author verification signature proving
authorship in cases of dispute or theft.
The algorithm design will be specified in a document called
DEA2TECH.DOC. It will be distributed to the INTERNET on or before
December 14, 1993. It should answer most questions that will arise.
Nellis du Maurier Information Security at its sole discretion, may,
in a very few limited cases, supply the source code for the DEA only
to qualified crypto professionals who need to be able to modify the
source code at various points to allow selected DEA statistics to be
gathered for inspection and analytic purposes.
Chapter Nine
═════════════════
9.1 THE DEA v.2.00 FILE SIZE DOUBLING PROBLEM
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
The DEA v.2.00 will double the size of the input file. This is an
annoyance which both Nellis du Maurier and its users can live without.
This problem emerged from the design of the new Cipher Function
specifications. The issue was addressed, but no satisfactory method was
found. Nellis du Maurier actively seeks user input regarding this problem.
If you think you have found a reliable and efficient method to eliminate
this problem, please send your ideas along with 'C' language source code
example to the publisher. If your implementation is selected, it will be
incorporated into the DEA, and the new version will be available to all.
You will also be notified by mail of this decision.
The problem is stated as follows:
Design an algorithm which can convert a numerical value larger than
256 ('C' int data type) into a value less than or equal to 256.
Specifically, an algorithm which can convert a 16-bit value into an
8-bit value, WITHOUT LOSS OF PRECISION of the 16-bit value.
Thus, a DEA Stop Address such as 14,851 (16 bits) must be converted
to an 8 bit data entity to prevent DEA ciphertext from expanding.
Of course, the 8-bit value must allow the recovery of the actual DEA
Stop Address of 14,851 EXACTLY, to allow the DEA to recover the
enciphered message. A possible working idea might be a square
root function in which the mantissa is discarded, but recovered
via some algorithmic technique.
Additional Information
══════════════════════
Nellis du Maurier Information Security is a registered company
operating in the province of Ontario. It designs, markets, and sells
computer information security products using the DEA technology.
The company is registered at:
Companies Branch
Ministry of Consumer and Commercial Relations
375 University Avenue, Second Floor
Toronto, Ontario M7A 2H6
Canada
APPENDIX
════════
TIMING FUNCTION
ERROR MESSAGES
WHY WAS THE GENKEY PROCEDURE NOT AUTOMATED?
DEA COMMERCIAL VERSION
CLEARING THE INTERNAL KEY DATA STRUCTURE
A HELPFUL HINT FOR FREQUENT COMMAND LINE USAGE
ANOTHER METHOD OF THE CREATING THE DEA KEY
PROGRAM EXIT CODES - DEA.EXE only -
TIMING FUNCTION
---------------
The process time recording function used in the DEA does not provide
midnight roll-over. For example, if you begin enciphering at system
time 11:57pm, and the DEA process requires 5 minutes, the displayed
time will not be correct; it may even show a value in the billion range.
This is not really an error, it is a limitation of the library function
itself which does not have this capability. This curio should not display
itself too often. The process timing function does not provide EXACT
timing; it provides an approximation. This strategy was chosen so as
to avoid the inline floating point math emulation instructions which would
have made the DEA.EXE file larger by about 25,000 bytes, and somewhat
slower.
The times shown on the screen following a DEA process, are approximations;
they are shown in seconds (quite precise), minutes (fairly accurate), and
hours (this should show zero most of the time, unless it actually takes
that long)
ERROR MESSAGES
--------------
All programs in this package will generate error and / or usage messages
if invalid data is supplied. Error return codes are listed below in the
section PROGRAM EXIT CODES.
WHY WAS THE GENKEY PROCEDURE NOT AUTOMATED?
-------------------------------------------
Perhaps the most awkward and labour intensive aspect of the DEA package
lies in the GENKEY utility. Once a DEA key has been established, using the
DEA is a very simple matter indeed. It was suggested that a random number
generator function could be employed to quicken and automate the key
generation process. Despite the intuitive flexibility so obtained, it can
be shown to drastically reduce the security of the DEA. Here is why:
If a random number function is used to generate all aspects of the DEA
key data, then the random number function must be INITIALIZED FIRST,
otherwise we run the risk of having DEA users across the entire country
using the SAME KEY!
Suppose that the random number generator can be initialized, now the
problem is that there are a limited number of ways in which the PRNG CAN
BE INITIALIZED, for most such PRNG's, there are only 32,767 initializer
'seeds' AVAILABLE. Even if there were 4 billion (256^4) different
ways to initialize the PRNG, 256^4 is no comparison to the DEA's
keyspace of 256^180.
The problem with automated key generation via a pseudo random number
generators is that there are far fewer seeds to initialize them as there
are keys in the DEA design. Consider, for a moment, that we are
automatically generating a DEA key via this method, the user supplies a
PRNG seed value, and then GENKEY produces a key. Since there are only
32,767 seed values for the PRNG, GENKEY can only produce 32,767 distinct
keys! Now, an attacker's task of finding the correct DEA key has been
reduced from 2^1,440 to 2^15.
Of course, several PRNG's could be used for the prime divisors,
numerators, imaginary fractions, select digits, and SABV's. However, this
brings the attacker much closer to realistically breaking the DEA. Several
PRNG's for GENKEY still make the attacker's task a relatively easy one, as
the work factor is reduced from 2^1,440 to 2^60. Thus, in essence, a DEA
key derived via pseudo random means makes the DEA just a little more
difficult to break by brute-force than the DES, which as we know, can be
brute-forced in 24 hours, or less in this day and age.
Thus, although GENKEY is labour intensive, this crude, but purely random
number selection method must be used to guarantee the integrity of the
extremely large key space of the DEA; any PRNG automation of GENKEY
reduces the keyspace to an almost insignificant magnitude. Generating the
key manually is the only way to guarantee the randomness of the 1,440 bit
key. In a manner of speaking, GENKEY represents the price to be paid
for using the DEA.
DEA COMMERCIAL VERSION
----------------------
Although this release of the DEA is far superior to all other currently
available commercial and shareware information security products, more
security is unequivocally better in cryptography. Given the constant
speed increases of computers, the DEA can stay far ahead of any likely
brute-force attacks via the agency of:
1. greater number of file blocks from the present ten (10) to say, 20 +
2. a user defined 200 byte (1,600 bit) random supplemental key
3. post DEA encryption via any available encryption algorithm
Any one, or all of the above will help to maintain privacy longer in the
face of ever faster computers.
The DEA Advanced Commercial Version (DEA ACV 2.00) will address the issue
of yet higher security via an expanded keyspace using a user defined 200
byte random key. This key shall be incorporated into the existing DEA key
data structure. However, key incompatibilities between the standard DEA
and the DEA ACV will arise. If you are a registered user of both programs,
Nellis du Maurier will supply a conversion utility to ensure key
compatibility across both versions.
Availability of the ACV will be December 1993 or January 1994.
Effective keyspace of the DEA ACV is:
2^2,304,000 or 256^36,000
Please note that the DEA ACV 2.00 will not be marketed via the Shareware
distribution method. It will only be available to registered users of the
DEA Release v.2.00.
CLEARING THE INTERNAL KEY DATA STRUCTURE
----------------------------------------
Please note that the key data stored in the DEA key data structure during
DEA processing is cleared to zero at the time of normal program exit. This
assures you that no sensitive key data remains active in computer memory
which could be found by a memory scanning utility.
Note that all programs which use the DEA key data structure (DEA, GENKEY,
& KEYVIEW) clear this data structure to zero before exit as well.
A HELPFUL HINT FOR FREQUENT COMMAND LINE USAGE
----------------------------------------------
If you routinely use the DEA to encrypt and decrypt files, you may get
tired with having to type the command line every time you perform a DEA
operation. Command line usage can be made much more simple by using the
following tip which relies on batch files. This is only useful if you do
not change key ID values and OTP values frequently.
Create a batch file with just the following contents:
DEA /E /K4 /OTP4713 %1 %2
you can give this batch file the name "DEA-E.BAT" to signify encryption
via the DEA.
Create another batch file with just the following contents:
DEA /D /K4 /OTP4713 %1 %2
give this batch file the name DEA-D.BAT for example, to signify
decryption via the DEA.
Now, whenever you wish to use the DEA, you can simply specify either:
DEA-E file_in
or
DEA-E file_in file_out
or
DEA-D file_in
Some Observations:
1. this is for MS-DOS usage
2. no flexibility in choosing OTP values
3. no flexibility in choosing key ID values
4. simple and short 'new' format
5. DOS redirection pipes will NOT work correctly
When you want to change your key ID values and / or OTP settings, you
should remember to edit your DEA-E and DEA-D batch files also.
ANOTHER METHOD OF CREATING THE DEA KEY
--------------------------------------
Here is a method which can be used to generate a DEA key. Although the
data thus generated must be typed into the GENKEY program, the user is
relieved from most of the task of thinking up the numbers. Remember
that the technique described here cannot be used to generate a DEA key
for immediate use by the DEA; it must still be submitted to GENKEY
first.
Here then, is the method:
1. run the KeyView utility, but instead of the normal file "DEA.KEY",
specify another file type. It could be a .GIF, .PCX, .ZIP,
.DEA, .EXE, .COM, .TXT, .DBF, or ANY OTHER FILE. KeyView will
determine the number of keys available by dividing the said file type
by 240. Remember that these are fictional DEA keys, but we just want
to get some random numbers fast.
2. select a key from the available ones listed by KeyView
3. make a copy of KeyView's output file DEA_KEY.ASC, preferable on
paper, or in a multi-windowed text editor. We must now change
some values to acceptable ranges before submitting the key to
GENKEY. In particular, we must make certain that the prime
divisors are within proper ranges, and that other DEA key data is
of proper data size. SABV: 0-255, SD: 0-9. For the prime divisors,
you must make certain that ODD INTEGERS are entered, further, the
PD's should not be enormous; see the Chapter 3.10 VALID DEA KEYS
for further information.
If you are still unsure as to the changes you must make to a DEA key
from KeyView via this method, it is suggested that you examine the
real DEA key with KeyView, and then create another DEA 'key' via this
technique.
PROGRAM EXIT CODES - DEA.EXE only -
------------------
Code Meaning
---- -------
0 normal program start and exit
1 cannot open DEA.KEY file, even after the user is queried
2 selected one-time-pad is out of range
3 same as (2) above, different line number
4 unknown cipher mode
5 same as (2) above, different line number
6 cannot open input file -possibly the file does not exist,
is misspelled, or is READONLY
7 cannot write output file -possibly not enough space,
invalid path (embedded DEA path)
8 cannot open DEA.LOG file
9 same as (4) above, different line number
10 non-integral key file size - DEA.KEY file modulo 240 = 0
11 invalid key ID reference number
ACKNOWLEDGMENTS
═══════════════
Nellis du Maurier Information Security wishes to extend a note
of thanks to the many individuals who spread quickly and widely the
DEA v.2.00. Sincere thanks also goes out to Mr. Philip Latimer, and
Mr. Sander Schimmelpenninck who were both very much responsible for the
DEA's maturity into a sophisticated, powerful, and useful software tool.
Thanks also to the very many unnamed individuals who took the time to
both download and later re-post this archive to their local bulletin
boards. Thanks to all of you, you now have a software tool to fully
protect your god-given right to information privacy. A tool which is
head and heels above all others. A genuine Nellis du Maurier product
you can use with justifiable assurance and confidence.
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀